IFX Mail Archive: IFX> Notes on the IFX and IPPGET part of t

IFX Mail Archive: IFX> Notes on the IFX and IPPGET part of t

IFX> Notes on the IFX and IPPGET part of the IPPFAX telecon, Friday, A ug 17

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Mon Aug 20 2001 - 21:17:14 EDT

  • Next message: Hastings, Tom N: "IFX> Notes on the UIF part of the IPPFAX telecon, Friday, Aug 17"

    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