I've separated the notes about the UIF part and the IFX part of our IPPFAX
telecon, Friday, August 17, since the former will be sent to the Internet
FAX WG (ietf-fax@img.org), but the IFX notes will not. The added IPPGET
issue 48 about URI matching was also raised and agreed and will be
distributed to the IPP DL separately as well.
Please send any comments about the notes to the mailing list.
Agenda:
10-11 AM - Address the Internet FAX WG concerns about UIF and the Adobe IPR
issues with TIFF/FX.
11-12 AM - continue with IFX issues 43, 45-47. Any IPPGET Issues.
Attendees: John Pulera (Minolta Labs), Marty Joel (Netreon), Ira McDonald
(High North), Rob Buckley (Xerox), Peter Zehler (Xerox), Tom Hastings
(Xerox), Gail Songer (Netreon).
Summary of the IFX Part:
We resolved all of the issues. Tom Hastings will update the IFX and IPPGET
drafts. Ira McDonald and possibly Marty Joel will review the updates for
correctness with our agreements and resolve minor issues that arise as a
result. Any major issues will be flagged.
We re-affirmed the need for a new URL scheme for 'ippfax' with a well-known
port, whether or not it can be a system port (less than 1024). It will have
parameters sec= and auth= as was discussed for the 'ipp' scheme, and will
have means to extend the parameters for possible future off-ramp use. Which
URL is used indicates whether ipp or ippfax semantics are to be performed,
rather than any operation attributes.
We agreed on each TLS feature that is REQUIRED or OPTIONAL.
Summary of the IPPGET Part:
We reaffirmed not using the "notify-recipient-uri" for searching in
Get-Notifications. We agreed to add a Printer Description attribute which
indicates that the Receiver is configured to notify the recipient of the
completion of an IPPFAX job using implementation-dependent means, so that
the Sender can avoid sending duplicate notifications to the recipient.
Details:
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
URL scheme:
We re-affirmed the need for a new URL scheme for 'ippfax' with a well-known
port, whether or not it can be a system port (less than 1024). It will have
parameters sec= and auth= as was discussed for the 'ipp' scheme, and will
have means to extend the parameters for possible future off-ramp use. Which
URL is used indicates whether ipp or ippfax semantics are to be performed,
rather than any operation attributes.
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"
AGREED> Yes.
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.
AGREED> Yes.
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.
AGREED> Yes.
AGREED> We also agreed that when querying jobs with Get-Jobs and/or
Get-Job-Attributes, whether or no you can see jobs that were submitted with
another scheme, DEPENDS ON IMPLEMENTATION. However, viewing IPPFAX jobs
with any URL, including ippfax, MUST restrict certain attributes that are
consistent with a public service, such as "job-name" and
"job-originating-user-name".
AGREED> We also agreed that for controlling jobs, such as Cancel-Job,
Set-Job-Attributes, Hold-Job, etc. the client MUST use the same URL as the
URL that was used to submit the job. Authenticated operators MAY use other
URLs, depending on implementation and site security policy.
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.
AGREED> Yes.
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?
AGREED> Yes.
AGREED> We also agreed that with either method a or method b, an
administrator could set up a large number of URLs, one for each recipient
and/or one for each group of recipients. Then a separate user could be
given operator privileges for each URL. This approach may help a designated
person with operator privileges to run an application that creates a
Per-Printer Subscription object that listens for incoming IPPFAX jobs.
However, method b (either one IPPFAX URL per Printer object or all IPPFAX
URLs per Printer object, but in either case no IPP URLs) may be more
appropriate for this technique, so that only IPPFAX jobs can be submitted.
AGREED> If multiple IPPFAX URLs are allocated to a single Printer object,
then the value of the new Printer Description attribute that indicates
whether or not the Receiver is currently notifying recipients (in an
IMPLEMENTATION DEPENDENT MANNER) will depend on the URL on which the
Get-Printer-Attributes is submitted (as would the Printer's
"printer-is-accepting-job" Printer Description Attribute that is set by the
Enable-Printer and Disable-Printer operator operation.
...
ISSUE 45: Since 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.
AGREED> Yes.
ACTION ITEM (Ira): Resurrect the agreements on this specification when we
were considering the same parameters for the 'ipp' scheme, but abandoned
them because of incompatibility with deployed IPP implementations and the
need to convert to HTTP/1.0 URLs. However, we don't have that requirement
with IPPFAX. Send them to the IPPFAX DL for discussion so that they can be
included in the IFX document without a lot of additional discussion.
ISSUE 45b: We should also figure out how off-ramp parameters can be added as
parameters as well.
AGREED> Yes. Figure out how to extend the URL parameters in a way the
recipients can ignore parameters they don't understand, just as with any Job
Template attribute.
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]:
AGREED> We recognized that there is an important difference in the
conformance terms between a "A client MUST support" and "A client MUST use".
The former means that the Sender code implementation MUST contain the
feature though it NEED NOT be used in every Job Submission and the latter
means that the Sender MUST support and MUST always invoke that code in a
conforming Job Submission. If a Sender MUST use, then it MUST also support,
by definition. If a Sender MUST support, there needs to be an addition
statement about whether or not it MUST use. If a Sender MAY support, then
it MAY use by definition. However, for simplicity it is probably best to
always specify "support" and "use" in the same sentence. Similarly for the
Receiver.
NOTE: In the following text, additions and replacements to the IPP/1.1
[RFC2911] text are indicated in []. I've changed "IPP Printer" to
"Receiver" and "IPP Client" to "Sender" without [].
AGREED>
Senders and Receivers MUST support and MUST use TLS Data Integrity
Senders and Receivers MUST support and MAY use TLS Data Privacy
Senders MUST query Sending User for each Document before omitting TLS Data
Privacy
Senders SHOULD support and MAY use TLS Client Authentication, i.e., the
'certificate' keyword defined in [RFC2911] "uri-authentication-supported".
Receivers MUST support and MAY use TLS Client Authentication, i.e., the
'certificate' keyword defined in [RFC2911] "uri-authentication-supported".
8.1.1 Digest Authentication
Senders MUST support:
1. Digest Authentication [RFC2617].
2. MD5 and MD5-sess MUST be implemented and supported [and use?].
3. The Message Integrity feature [MUST] be used.
Receivers [MUST] support:
4. Digest Authentication [RFC2617].
5. MD5 and MD5-sess MUST be implemented and supported.
6. The Message Integrity feature [MUST] be used.
8.1.2 Transport Layer Security (TLS)
7. Receivers [MUST] support Transport Layer Security (TLS) [RFC2246] for
Server Authentication, [Data Integrity, and Data Privacy].
8. Receivers [MUST] also support TLS for Client Authentication.
9. Receivers MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher
suite as mandated by RFC 2246 [RFC2246].
10. All other [stronger] cipher suites are OPTIONAL; [weaker cipher suites
MUST NOT be supported or used].
11. An IPP Printer MAY support Basic Authentication (described in HTTP/1.1
[RFC2617]) for Client Authentication if the TLS channel is secured with Data
Privacy.
12. TLS with the above mandated cipher suite [or stronger] can provide such
a secure channel.
13. Sender MUST support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite
as mandated by RFC 2246 [RFC2246].
14. All other stronger cipher suites are OPTIONAL; weaker cipher suites MUST
NOT be supported and used.
AGREED> The cost of requiring the Sender or the Receiver to get a public
key from a Certificate Authority seems too expensive ($100) and an
administrative burden. Instead, doing what current browsers seems
sufficient:
AGREED> Sender or Receiver is deployed with the public keys of a number of
the top Certificate Authorities. If the Sender gets a public key that it
doesn't recognize from the Receiver, it MUST query the Sending User to see
if he/she trust the Receiver (just as browsers do today), before proceeding
with the Job Submission.
AGREED> Distribution of private keys to Senders or Receivers is outside the
scope of IFX, but if it is done over the network, it MUST be over a secure
channel. See Internet Key Exchange (IKE), RFC 2809.
8.2 Using IPP with TLS
AGREED> We agreed to replace the IPP/1.1 statements in section 8.2 about
using Upgrade Headers in HTTP/1.1 to upgrade to TLS, with:
The Sender MUST use only TLS for all IPPFAX operations on the IPPFAX URL.
The client MUST start the transaction in TLS, rather than using HTTP upgrade
requests. Here is a paragraph from the HTTPS informational RFC 2818, which
we should probably quote:
The agent acting as the HTTP client should also act as the TLS
client. It should initiate a connection to the server on the
appropriate port and then send the TLS ClientHello to begin the TLS
handshake. When the TLS handshake has finished. The client may then
initiate the first HTTP request. All HTTP data MUST be sent as TLS
"application data". Normal HTTP behavior, including retained
connections should be followed.
So comparing IPP/1.1 with IPPFAX from a client's point of view:
IPP/1.1 sequence:
1. Start TCP connection
2. Zero or more HTTP/IPP requests
3. HTTP/IPP request with Upgrade to TLS header
4. TLS handshake
5. finish the HTTP/IPP request securely
6. Send more HTTP/IPP requests securely ...
IPPFAX sequence:
1. Start TCP connection
2. Send TLS ClientHello
3. rest of TLS handshake
4. Send HTTP/IPPFAX requests securely ... (which usually will be a
Get-Printer-Attributes, followed by Validate-Job and/or Print-Job
operations).
ISSUE 47: In Toronto, we had 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).
AGREED> We decided to get rid of the "final-destination-uri" attribute as
well, so that there is no off-ramp vestiges left. Off Ramp additions can be
a separate OPTIONAL spec and should be based on the Internet FAX Off Ramp
work which is nearing completion.
****The following IPPGET ISSUE 48 will be copied to the IPP DL as well****
ISSUE 48: How will the Receiving User get notified of an IPP FAX Job
completion?
AGREED> We reconfirmed that IPPGET is not a suitable method for use with
Per-Job Subscription objects for notifying Receiving Users. IPPGET requires
that each user do something every time the Printer is started in order to
receive notifications. So we reconfirmed removing the uri matching function
from the IPPGET Get-Notifications operation, even though we realized that
there is no easy way for a client on a Receiver to search all Per-Job
Subscription Objects using Get-Subscriptions. First such a client would
have to poll using a Get-Jobs operation and see what new jobs had arrived
since the last poll. Then it would have to do a Get-Subscriptions for each
new job requesting the "notify-recipient-uri" attribute and match it.
If the IPPGET Delivery Method is used on a Receiver to notify Receiving
Users, it should be done by an operator application that creates a
Per-Printer Subscription object that subscribes to 'job-completed' events
for all Jobs. See agreement under ISSUE 49 (below) for further discussion
about possible ways a Receiver can notify Receiving Users.
The following affects the IPPFAX Protocol spec, not the IPPGET spec:
ISSUE 49: 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.
AGREED> Instead of adding a Job Template attribute to allow the client to
control the delivery of notification to Receiving Users, we agreed to simply
add a Printer Description attribute that is a boolean that indicates whether
or not the Receiver is currently configured to notify Receiving Users when
an IPPFAX Job completes, so that the Sender doesn't have to also worry about
notifying the Receiving User about the IPPFAX Job causing annoying duplicate
notifications for the Receiver User. If the Receiver isn't notifying
Receiving Users, then the Sender could notify Receiving Users either:
a. by adding another Subscription Object with a push method, such as
'mailto' or 'indp' (if supported) to the Job Creation operation with the
Receiving User as the "notify-recipient-uri", or
b. by sending an email message to the Receiving User (before or after the
job completes, depending on the wishes of the Sending User).
The IMPLEMENTATION DEFINED methods for the Receiver to notify Receiving Uses
of completed IPPFAX Jobs include:
1. Each Printer URI is for a separate user. Each Printer object has a
configured Per-Printer Subscription object or equivalent that is subscribed
to 'job-completed' events and uses a supported Event Notification Delivery
Method to deliver the notification to the configured user.
2. Each Printer object has a pre-allocated Per-Printer Subscription Object
that is subscribed to 'job-completed' events and that an operator
application uses to examine Job attributes, such as any fields in the Job's
"ippfax-receiving-user-vcard" operation/Job Description attribute and/or the
"printer-uri" and automatically notify the Receiving User by email,
telephone, or pager.
3. An operator/secretary launches an application that creates a Per-Printer
Subscription object that notifies the operator/secretary by some supported
Delivery Method (ippget, indp, or mailto).
4. That application could examine Job attributes, such as any fields in the
Job's "ippfax-receiving-user-vcard" operation/Job Description attribute
and/or the "printer-uri" and automatically notify the Receiving User by
email, telephone, or pager.
5. That application could access a central data base or directory for the
Receiving User as indicated in the "ippfax-receiving-user-vcard" and use the
method indicated there.
6. A person sits next to the Receiver and reads the start page and delivers
the documents to the Receiving User.
etc.
We did not get to review the following documents on operation conformance
and job template attribute conformance. Reviewers should look at them and
send any comments to the DL, so that we can discuss any issues before
putting these tables back into the IFX spec:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/white-sheet/ifx-operation-conformance.doc
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/white-sheet/ifx-operation-conformance.doc
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/white-sheet/ifx-job-template-attributes.d
oc
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/white-sheet/ifx-job-template-attributes.d
oc
This archive was generated by hypermail 2b29 : Mon Aug 20 2001 - 21:18:55 EDT