At Thursday's (8/9) telecon we agreed to hold another telecon to address the
IFX issues, next Tuesday (same time, same numbers):
Tuesday, August 14, 8-10 AM PDT (11-1 PM EDT)
Phone: 1(712) 884-1555, (Xerox folks: 8*596-5170), passcode: 654970
I'm copying the IPP DL because that are a number of issues that pertain to
IPP and how it is extended for IPPFAX and possibly other specialized
services. These issues are 42 through 45 which have to do with a possible
new 'ippfax' URL scheme, its parameters, Printer objects, and what semantics
depend on the URL supplied versus which Printer object is accessed. Please
respond to these (and other issues) before the telecon.
Here is the Agenda for the telecon:
Since we discussed all the IPPGET issues on Thursday and resolved all of
them, except ISSUE 11 (server increasing the poll time), 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
The remaining ISSUES in the IFX document are issue 32-41.
Issue 42-47 have been added since the meeting this week in talking with
Marty and Ira about the good agreements reached in Toronto (Issue 43 and 44
have been slightly augmented from the previous agenda, so please use this
agenda):
ISSUE 32: Do the conformance requirements look ok?
Need to register the new attributes and the new status code. Text TBD.
ISSUE 33: Need version 3.0 of vCard, since it an RFC, while version 2.1
is not.
vCard version 3.0 is RFC 2426 "vCard MIME Directory Profile", F. Dawson, T.
Howes. September 1998. (Format: TXT=74646 bytes) (Status: PROPOSED STANDARD)
ISSUE 34: Is this example accurate? The phone number format seem wrong.
ISSUE 35 (repeat): What vCard restrictions? No pictures, no logos, no
sound?
ISSUE 36: What other Receiver attributes should go in the Generic Directory
Schema for an IPPFAX Receiver?
ISSUE 37: OK that it is of abstract type printer?
ISSUE 38: Should the concrete type be 'IPP' (since the 'ipp' scheme is
being used), or 'IPPFAX' to differentiate it from an IPP Printer?
ISSUE 39: Is the conformance right?
ISSUE 40: Should we add authors to PWG standards like we do IETF RFCs?
ISSUE 41: Should we add participants to PWG standards like we do IETF RFCs?
The following NEW issues were discovered by Marty Joel, Ira, and myself when
going over the ISSUE resolutions from the meeting.
ISSUE 42: What attributes, attribute values, and operations does a client
see with Get-Printer-Attributes depending on the URL being used (independent
of whether or not we have a new URL scheme - see ISSUE 03)?
ISSUE 42a: According to IPP/1.1, the three parallel "printer-uri-supported",
"uri-security-supported", and "uri-authentication-supported" (the three
musketeers) always returns all values for all schemes, so these three
attributes aren't colored in any way, right?
ISSUE 42b: If a single Printer object supports IPP and IPPFAX with separate
URLs, and a client queries on the IPP URL, does it get back the "ippfax-xxx"
attributes or not?
ISSUE 42c: If we have a separate URI scheme (ISSUE 03), then there is no
need for the newly renamed "semantics-supported" (was
"ippfax-semantics-supported") Printer attribute at all? Instead, the
"printer-uri-supported" serves the same purpose. However, if we don't have
a new IPPFAX URL scheme, will the "semantics-supported" Printer attribute
act like the three musketeers and return all semantics supported no matter
on which URL the client queries?
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 4 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"
"semantics-supported" -- our new attribute with 'ipp' and/or 'ippfax'
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
(whether or not we have a new IPPFAX scheme)? (Part of ISSUE 11 resolution)
ISSUE 43b: Do we agree that all other attributes (except these 4) 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 four
special attributes "printer-uri-supported", "uri-authentication-supported",
"uri-security-supported", "semantics-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 44: If we do have a new 'ippfax' URL scheme, then the scheme
indicates whether IPP or IPPFAX semantics are wanted, right? Then
"ippfax-version" operation attribute (decision on issue 11 to replace the
"ippfax-semantics" operation attribute), only becomes a version indication,
and NOT a request to use IPPFAX semantics, right?
ISSUE 44a: If we don't have a new 'ippfax' URL scheme, then which URL the
client supplies still indicates whether IPP or IPPFAX semantics are wanted
for all operations, right? Its just harder for the client to tell which
URL to use in order to get IPP versus IPPFAX semantics.
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 : Fri Aug 10 2001 - 14:44:19 EDT