IFX Mail Archive: IFX> Notes from IPPFAX telecon, Tuesday, A

IFX Mail Archive: IFX> Notes from IPPFAX telecon, Tuesday, A

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

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Tue Aug 14 2001 - 21:02:48 EDT

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

    Attendees: Ira McDonald (High North), Gail Songer (Netreon), Marty Joel
    (Netreon), Cark Kugler (IBM), Scott Foshee (Adobe), Tom Hastings (Xerox).

    Summary:

    We discussed IFX Issues 32-42 and 44. We also discussed Adobe's IPR
    concerns about the TIFF license granted to the IETF. We agreed to have
    another telecon to resolve the remaining IFX issues:

    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.

    Details:

    Scott Foshee from Adobe joined us for the entire telecon and explained that
    he is the Adobe contact person for TIFF. At the end of the telecon, he told
    us about last week's IETF FAX WG meeting at the IETF meeting in London. He
    told us that Adobe had raised to the IESG and IAB their concerns about the
    TIFF license that they had granted to the IETF for use in TIFF/FX. Scott
    explained that the IETF FAX WG is likely to split the TIFF/FX document into
    two parts, one part that is compatible with existing TIFF readers (probably
    profiles S and F) and the other that has the extensions (probably profiles
    J, C, L, and M). He suggested that this Internet FAX changes might impact
    our IPPFAX schedule.

    He also explained that the IEEE-ISTO would probably need to get a license
    from Adobe for TIFF for use with UIF.

    We also talked about the possibility of using PDF/X.1 (an ISO standard)
    instead of or in addition to UIF. Scott will pass this possibility on to
    the Acrobat Group in Adobe to see if they want to come join the IPP FAX WG.

    Scott will be on vacation starting Thursday, August 16, returning September
    6.

    For the first 110 minutes of the call, we continued reviewing the IFX issues

    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?

    The conformance section has many changes, since we have agreed to many
    changes:

    1. The Sender MUST supply and the Receiver MUST support the
    "ippfax-semantics" operation attribute in all operations to get the IPPFAX
    semantics as described in section 3.2.

    Now its the IPP versus the IPPFAX URL that controls the semantics.

    2. The Sender MUST query and the Receiver MUST support the attributes
    using the Get-Printer-Attributes operation as described in sections 4 and 5
    and Table 1.

    Toronto: agreed that the Sender MUST either query as above or use the
    Validate-Job operation.

    3. The Sender MUST supply and the Receiver MUST support the
    operation/Job Description attributes for Identify Exchange as described in
    section 6.

    Toronto: agreed that its a MAY for the Sender and a MUST for the Receiver.

    4. The Sender MUST support submitting and the Receiver MUST accept
    IPPFAX Jobs as defined in section 7 and Table 2, Table 3, Table 4, and Table
    5.

    Still true subject to the changes.

    5. The Sender MUST place the Sender's identity on every page as
    required in section 7.8.

    Still true, but agreed that the Sender's identity is the same value as the
    "ippfax-sender-uri" (uri) operation/Job Description attribute. Need to talk
    to Lloyd about what FAX identity is legally binding. We should leverage the
    legal status of FAX identity.

    6. The Sender and Receiver MUST support the operations as indicated in
    section 8 and Table 6.

    We agreed that the entries in Table 6 need three columns for the Receiver:
    job owner, operation, other and that there are entries which say MUST, MAY,
    and MUST NOT. ACTION ITEM (Tom Hastings): propose the contents of these
    columns to the DL based on the discussion. For example the Receiver MUST
    NOT accept Cancel-Job for the owner and others, but MAY accept for the
    Operator. The Receiver MUST accept Get-Subscription-Attributes and
    Get-Subscriptions for the owner. We also agreed that a user doing a
    Get-Job-Attributes or a Get-Jobs on an IPP URL MAY see IPPFAX jobs, just
    like any other non-IPP protocol. However, certain attributes, such as
    "job-name", and "job-originating-user-name" MUST NOT be returned.

    7. The Sender and Receiver MUST support the security mechanisms
    indicated in section 9, including TLS.

    No change.

    8. If the Sender and Receiver support Off-Ramps, they must support the
    attributes defined in section 10.1.

    Off-ramps have been deleted from this document. We may put them into a
    separate document as an OPTIONAL extension, if there is interest.

    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.

    Unresolved. ACTION ITEM (Ira): Find out how widely the vCard 3.0 is
    deployed.

    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.

    At least fix phone number to use "-" to be correct.

    ISSUE 35 (repeat): What vCard restrictions? No pictures, no logos, no
    sound?

    Receiver is not required to store pictures, logos, and sound on the Job
    object (but Sender MAY include).

    ISSUE 36: What other Receiver attributes should go in the Generic Directory
    Schema for an IPPFAX Receiver?

    These look fine, except "ippfax-semantics-supported" is gone, since
    "printer-uri-supported" tell whether or not ippfax is supported by the
    scheme.

    Also a Printer that supports both IPP and IPPFAX should advertise them
    separately, since they are separate services.

    Finally, an IPPFAX Printer advertises document-format-supported as the
    formats that it supports for the IPPFAX service. If an implementation
    and/or an administrator wants to support additional document formats, such
    as Postscript, that don't have the guarantees that UIF has, then the Sender
    MUST query the User before sending the document. We'll still call this
    fallback, since fallback to IPP has gone away with having separate URLS for
    IPP versus IPPFAX.

    ISSUE 37: OK that it is of abstract type printer?

    Yes, though in the future, it could also be fax.

    ISSUE 38: Should the concrete type be 'IPP' (since the 'ipp' scheme is
    being used), or 'IPPFAX' to differentiate it from an IPP Printer?

    The concrete type MUST be ippfax to agree with the new scheme.

    ISSUE 39: Is the conformance right?

    Looks ok.

    ISSUE 40: Should we add authors to PWG standards like we do IETF RFCs?

    Yes.

    ISSUE 41: Should we add participants to PWG standards like we do IETF RFCs?

    Yes.

    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)?

    On the IPP URL, the client sees IPP, but NOT IPPFAX attributes. On the
    IPPFAX URL, the client sees IPPFAX attributes, plus all of the IPP
    attributes, but with values that pertain to IPPFAX.

    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?

    Yes.

    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?

    It does NOT get back "ippfax-xxx" attribute on the IPP URL.

    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?

    We are going to get a new scheme and either have a well know system port
    (less than 1024) or at least a well know port (1024 to 32K range).

    ...

    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?

    Yes, "ippfax-version" only indicates the IPPFAX version and the URL
    indicates whether IPP versus IPPFAX semantics are to be used. If a Sender
    sends an "ippfax-version" operation attribute on an IPP URL, the Receiver
    MUST still accept the request, but return it as an ignored attribute.

    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.

    Moot, since we've agreed to have a new URL scheme.

    End of telecon.



    This archive was generated by hypermail 2b29 : Tue Aug 14 2001 - 21:03:38 EDT