Internet FAX WG,
I'm remiss in not sending this announcement sooner about an IPPFAX telecon
tomorrow. Based on the minutes from London, there is concern about
incompatibility with UIF and TIFF/FX:
Here is the statement about the IPPFAX presentation that Lloyd McIntyre made
at the
Internet FAX WG at the IETF meeting:
5.4 PWG IPP Fax status report
Lloyd reported on behalf of the PWG IPP group. (see slides for a detailed
description of documents and status). Is was made clear that the activity
presetnte is carried on within the IEEE unbrella, and also that the IESG
did not accepted this activity as a possible IETF one, answering that
these activities were already covered by our wg. There was consensus from
the wg that there must be a better coordination with these external
efforts, in order to avoid any possible incomaptible products to be
developed.
The slides that Lloyd presented are available at:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/slides/IPPFAX-status-010729-at-ietf51.ppt
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/slides/IPPFAX-status-010729-at-ietf51.pdf
So the first hour of our telecon will be about both the Internet FAX WG
concerns about incompatibility between UIF and TIFF/FX and the Adobe IPR
concerns about TIFF/FX.
If you can't join us, but have input for either the first or second hour,
please send email to ifx@pwg.org.
Thanks,
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Tuesday, August 14, 2001 16:31
To: IPP FAX DL (E-mail)
Subject: IFX> Agenda IPPFAX telecon, Friday, Aug 17, 10-12 AM PDT (1-3
PM EDT )
At today's (8/14) telecon we agreed to hold another telecon to address the
IFX issues, next Friday (starting time two hours later, same numbers):
Friday, August 17, 10-12 AM PDT (1-3 PM EDT)
Phone: 1(712) 884-1555, (Xerox folks: 8*596-5170), passcode: 654970
10-11 AM - Address the concerns about UIF and the Adobe IPR issues with
TIFF/FX.
11-12 AM - continue with IFX issues 43, 45-47.
I believe that we have agreed to have a new ippfax URL scheme and that the
scheme used (ipp vs. ippfax) indicates which semantics the Printer uses.
I'll write this up more for the minutes of today's telecon.
Here is the Agenda for the telecon:
We'll continue reviewing the IFX issues first on the IFX spec version D0.6,
posted 7/27:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf .doc
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf .doc
IFX Issues 1-31 were covered or postponed at the Toronto meeting. See the
minutes at:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0108-minutes.doc
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0108-minutes.pdf
and IFX Issues 32-42 and 44 were covered at today's telecon (notes
forthcoming).
The remaining ISSUES in the IFX document are issue 43 and 45-47:
ISSUE 43: Do we still agree that there are two ways for a single
implementation to support both IPP and IPPFAX (whether we have a new URL
scheme or not, there is still an IPP URL versus an IPPFAX URL):
Method a: A single Printer object supports both semantics with separate
URLs. Depending on which URL the client supplies, the IPP versus IPPFAX
semantics are performed. The following 3 Printer object attributes
return the same values for all URLs used as a target, i.e., the values
returned do NOT depend on the URI supplied in the Get-Printer-Attributes
request:
"printer-uri-supported" -- our three IPP/1.1 musketeers
"uri-authentication-supported"
"uri-security-supported"
ISSUE 43a: Do we agree that a single Printer object (Method a) cannot use
the same URL for both IPP and IPPFAX, i.e., the URL must be distinct.
ISSUE 43b: Do we agree that all other attributes (except these 3) returned
by Get-Printer-Attributes depend on the URI supplied as the target, i.e.,
the values are not the union of the values for all URIs supported by the
Printer object? So for example, "document-format-supported" and
"operations-supported" depends on the URI supplied, "ippfax-xxx" attributes
are only returned when the IPPFAX uri is supplied, and none of the
"ippfax-xxx" attributes are returned when an IPP URI is supplied.
Method b: Two separate Printer objects (on the same host), also with
separate URLs. Depending on which URL the client supplies, the IPP versus
IPPFAX semantics are performed. The System Administrator configures each
Printer object independently of the other. Each Printer object's attributes
contain only values for either IPP or IPPFAX, but not both. So the 3
special attributes "printer-uri-supported", "uri-authentication-supported",
"uri-security-supported", as well as all others contain values for one or
the other but not both.
ISSUE 43b: Should we RECOMMEND that if a single implementation has separate
Printer objects (Method b), one for IPP and the other IPPFAX, that the URL
differ only in the scheme? Then a client could try the same URL with the
other scheme?
...
ISSUE 45: If we have a new IPPFAX URL scheme, then we can have parameters
on it if we spec them now (unlike the IPP scheme). OK? What parameters
should we specify:
ISSUE 45a: How about auth= and sec= corresponding to the
"uri-security-supported", and "uri-authentication-supported" attributes.
These are ones we had wished we has specified for the IPP scheme, but
couldn't because of deployment of IPP. Then a URL completely specifies how
to connect to the Printer object.
ISSUE 45b: We should also figure out how off-ramp parameters can be added as
parameters as well.
ISSUE 46: What TLS options are REQUIRED for IPPFAX? This issue is an
outgrowth of ISSUE 03 (new scheme), but is really separate. IPP only
RECOMMENDS TLS and some of its options. Here are the IPP Security
conformance requirements from RFC2910 [numbers added]:
8.1.1 Digest Authentication
IPP clients MUST support:
1. Digest Authentication [RFC2617].
2. MD5 and MD5-sess MUST be implemented and supported.
3. The Message Integrity feature NEED NOT be used.
IPP Printers SHOULD support:
4. Digest Authentication [RFC2617].
5. MD5 and MD5-sess MUST be implemented and supported.
6. The Message Integrity feature NEED NOT be used.
8.1.2 Transport Layer Security (TLS)
7. IPP Printers SHOULD support Transport Layer Security (TLS) [RFC2246] for
Server Authentication and Operation Privacy.
8. IPP Printers MAY also support TLS for Client Authentication.
9. If an IPP Printer supports TLS, it MUST support the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246
[RFC2246].
10. All other cipher suites are OPTIONAL.
11. An IPP Printer MAY support Basic Authentication (described in HTTP/1.1
[RFC2617]) for Client Authentication if the channel is secure.
12. TLS with the above mandated cipher suite can provide such a secure
channel.
13. If a IPP client supports TLS, it MUST support the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite as mandated by RFC 2246
[RFC2246].
14. All other cipher suites are OPTIONAL.
8.2 Using IPP with TLS
15. IPP/1.1 uses the "Upgrading to TLS Within HTTP/1.1" mechanism [RFC2817].
16. An initial IPP request never uses TLS.
17. The client requests a secure TLS connection by using the HTTP "Upgrade"
header, while the server agrees in the HTTP response.
18. The switch to TLS occurs either because the server grants the client's
request to upgrade to TLS, or a server asks to switch to TLS in its
response. 19. Secure communication begins with a server's response to
switch to TLS.
ISSUE 47: We have agreed to remove the Off-Ramp attributes, but keep only
"final-destination-uri" which might be a urn of the recipient (see
resolution to ISSUE 29). However, should we have an attribute that is
similar which is to notify the recipient (person) of the arrival of the
document? The URI could be 'mailto', 'tel'. For the former, the IPPFAX
Receiver sends an unsolicited email message saying that a document has been
printed. The latter makes a phone call to announce that the document has
been printed. This attribute does not require the recipient to have done
anything ahead of time and does not require the recipient to be registered
in any system. It is what a secretary typically does today when a FAX is
received at a group FAX.
This archive was generated by hypermail 2b29 : Thu Aug 16 2001 - 14:15:37 EDT