IFX Mail Archive: IFX> Agenda IPPFAX telecon, Tuesday, Aug 1

IFX Mail Archive: IFX> Agenda IPPFAX telecon, Tuesday, Aug 1

IFX> Agenda IPPFAX telecon, Tuesday, Aug 14, 8-10 AM PDT (11-1 PM EDT )

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Aug 10 2001 - 14:40:45 EDT

  • Next message: Marty Joel: "IFX> ippget and Lost Events"

    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:41:33 EDT