IFX Mail Archive: IFX> FW: Agenda IPPFAX telecon, Friday, Au

IFX Mail Archive: IFX> FW: Agenda IPPFAX telecon, Friday, Au

IFX> FW: Agenda IPPFAX telecon, Friday, Aug 17, 10-12 AM PDT (1-3 PM EDT )

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Thu Aug 16 2001 - 14:13:37 EDT

  • Next message: IPP: "IFX> Wired News :Russian Adobe Hacker Busted"

    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