IFX Mail Archive: IFX> Revised agenda for the IPPFAX WG meet

IFX Mail Archive: IFX> Revised agenda for the IPPFAX WG meet

IFX> Revised agenda for the IPPFAX WG meeting in Toronto, Aug 1

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Jul 27 2001 - 20:21:05 EDT

  • Next message: McIntyre, Lloyd: "IFX> RE: comments on tiff-fx & schema extension drafts"

    This mail note supersedes the previous ones on suggested IPPFAX WG agenda
    for the Toronto meeting. This mail note lists each document to be reviewed.
    I've included the issues that are included in each document and the ones
    that have come up on the mailing list this past week. I have not been able
    to update the IPPGET spec with the discussion that we have had this week
    after last Friday's IETF deadline (7/20). So the IPPGET spec that was sent
    to the IETF last Friday and announced on Monday (7/23) should be used.

    As I said before, there are three IPP FAX documents that could be covered at
    the IPP FAX WG meeting. In the past, we have only been able to cover one
    such document in a full day and for this meeting the PWG plenary takes up
    some of the time. The IPPFAX WG will need to decide whether to focus on one
    document and which one, or try to go through the issues that are raised
    explicitly in each document. I suggest the latter approach.

    The UIF spec has 5 issues and is in good shape.
    The IFX spec has 41 issues and needs real review.
    The IPPGET spec is in pretty good shape with 7 issues.

    The documents are:

    1. UIF spec version D0.6, John Pulera posted Wednesday, 7/25 at:
    ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-06.pdf
    ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-06-edit.pdf

    2. IFX (IPP FAX Protocol) spec version D0.6, I posted today, 7/27:
    ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf
    ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf

    3. IPPGET Delivery Method (<draft-ietf-ipp-notify-get-04.txt>), I posted
    Monday, 7/23, at:
    ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717-rev.pdf
    ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717.pdf

    4. Drafts TIFF-FX Extension 1 and Schema Extension 1
    Lloyd McIntyre called our attention to last Monday, 7/23. As soon as it is
    approved we can add a Profile T (JBIG2) to our UIF document. Here it is
    important to send any comments to the Internet FAX DL (<ietf-fax@imc.org>)
    as well as the IPP FAX DL (<ifx@pwg.org). However, sending comments can be
    and should be sent individually, but needs to be done before August 4 for
    the IETF meeting.

    5. Look at the schedule

    I'll not be attending, though Marty Joel and John Pulera will. Also Peter
    Zehler will be attending from Xerox and is very familiar with IPP. John
    Pulera will take care of the UIF spec. I'd be glad to help update the IFX
    and IPPGET specs, but someone needs to take good notes. If someone could
    answer each issue in this mail note as agreed by the group, plus whatever
    else is agreed, that would be a simple way to take notes.

    Here are the explicit issues in each document or that have been raised on
    the mailing list this week:

    1. UIF spec version D0.6, John Pulera posted Wednesday, 7/25 at:
    ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-06.pdf
    ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-06-edit.pdf

    UIF ISSUE 1. Should the capabilities discovery portion of this spec be
    removed and placed into a specification that deals solely with how IPPFAX
    uses capabilities discovery? Advantages: other applications interested in
    using UIF simply as a data format can do so (no prohibitive excess baggage).

    UIF ISSUE 2. Should we break UIF Profile C into two profiles-one to
    represent a baseline grayscale configuration and the other to represent a
    baseline color configuration? This way, a greater number of device
    capabilities configurations would be allowed without requiring an
    implementation of CONNEG. (The same could apply to UIF Profile L)

    UIF ISSUE 3. Should we add the CONNEG tag "profile" and tag values
    "uif-s", "uif-f", "uif-c", etc., to represent the incremental differences
    between minimum capabilities strings listed in sections 4.1.2.1 through
    4.1.2.5? This would cut down on the length of the CONNEG strings, especially
    for the composite UIF profile M) and would make it immediately apparent from
    a human's perspective any OPTIONAL features that are advertised.

    Define "profile=uif-s" to mean

               (& (image-file-structure=TIFF-minimal)
                  (MRC-mode=0)
                  (image-coding=MH)
                  (color=Binary)
                  (dpi=[200,300,600])
                  (dpi-xyratio=1) )

            Define "profile=uif-f" to mean
               (& (image-file-structure=TIFF-limited-uif)
                  (MRC-mode=0)
                  (image-coding=MMR)
                  (color=Binary)
                  (dpi=[200,300,600])
                  (dpi-xyratio=1) )

            Define "profile=uif-j" to mean
               (& (image-file-structure=TIFF-limited-uif)
                  (MRC-mode=0)
                  (image-coding=JBIG)
                  (image-coding-constraint=JBIG-T85)
                  (color=Binary)
                  (JBIG-stripe-size=128)
                  (dpi=[200,300,600])
                  (dpi-xyratio=1) )

            Define "profile=uif-c" to mean
               (& (image-file-structure=TIFF-limited-uif)
                  (MRC-mode=0)
                  (color=full)
                  (image-coding=JPEG)
                  (image-coding-constraint=JPEG-T4E)
                  (color-subsampling="4:1:1")
                  (color-levels<=16777216)
                  (color-space=CIELAB)
                  (color-illuminant=D50)
                  (CIELAB-L-min>=0)
                  (CIELAB-L-max<=100)
                  (CIELAB-a-min>=-85)
                  (CIELAB-a-max<=85)
                  (CIELAB-b-min>=-75)
                  (CIELAB-b-max<=125)
                  (dpi=[200,300])
                  (dpi-xyratio=1) )

            Define "profile=uif-l" to mean
               (& (image-file-structure=TIFF-limited-uif)
                  (MRC-mode=0)
                  (color=grey)
                  (image-coding=JBIG)
                  (image-coding-constraint=JBIG-T43)
                  (JBIG-stripe-size=128)
                  (image-interleave=stripe)
                  (color-space=CIELAB)
                  (color-levels<=256)
                  (color-illuminant=D50)
                  (CIELAB-L-min>=0)
                  (CIELAB-L-max<=100)
                  (dpi=[200,300])
                  (dpi-xyratio=1) )

            Then, for example, we can rewrite the minimum capabilities string
    for UIF Profile M shown in Section 4.1.2.6 as
                    (| (profile=[uif-s,uif-c])
                       (& (image-file-structure=TIFF-MRC-limited)
                          (MRC-mode=1)
                          (MRC-max-stripe-size<=256)
                          (profile=[uif-s,uif-c])
                          (dpi=[200,300]) ) )
            As another example, if we would like to advertise a Receiver that
    can support UIF Profiles S, F, J with optional resolution of 1200 dpi for
    the black & white profiles and optional resolution of 600dpi for the color
    profile, we can say
            (| (& (profile=[uif-s,uif-f])
                     (dpi=[200,300,600,1200]) )
                  (& (profile=uif-c)
                     (dpi=[200,300,600]) ) )

    UIF Issue 4. (not in the document; see section 5.1.1) Should we change the
    MIME media registration to be simply a single value for the application
    parameter and add a new 'profile' parameter which is multi-valued to
    indicate the profiles that are in the document?

    So for a document that contains C and F on separate pages, instead of:

      image/tiff; application=uif-cf

    we'd have:

      image/tiff; application=uif; profile=uif-c,uif-f

    and for a document that contains MRC with C, L, and S, instead of:

      image/tiff; application=uif-mcls

    we'd have (in any order):

      image/tiff; application=uif; profile=uif-c,uif-l,uif-m,uif-s

    UIF ISSUE 5. (not in the document; see table 15) Profile M only lists 200**
    and 300** for background and foreground layers and doesn't mention the
    binary mask layer at all. We need to add the binary mask layer back in. OK
    to add 400** as a REQUIRED value for all three uses? MRC requires that the
    mask layer be an integral multiple (1, 2,3, ...) of the resolutions for the
    background and foreground layers. If we don't add 400** as a REQUIRED
    resolution, the mask layer would have to be the same as the background and
    foreground layers (200 or 300) unless an OPTIONAL resolution were used.

    2. IFX spec version D0.6, I posted today, 7/27:
    ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf
    ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf

    All of these issues are in the document:

    ISSUE 01: We did a lot of name changing at the telecon. Are these
    attribute names ok now? Check the TOC to see all the names together.

    ISSUE 02: I'm not completely happy with the organization of the document.
    Each attribute has its own section, so it appears in the TOC. Also I've
    tried to put the corresponding "xxx-supported" right next to the "xxx"
    attribute description, but in a separate section. However, several
    operation attributes appear more than once: "ippfax-semantics",
    "ippfax-profiles", and "document-format". Any suggestions or is this OK?

    ISSUE 03: OK that we are using the 'ipp:' scheme for both IPP and IPPFAX
    protocols?

    ISSUE 04: Can 'http' scheme be used in the "printer-uri" target attribute?
    Will 'http' be more likely to be configured to get through firewalls? What
    can a standards track RFC say about this since IPP/1.1 REQUIRES the use of
    the 'ipp' scheme?

    ISSUE 05: OK that we are forced to use the same default port for IPPFAX as
    for IPP? So if a Receiver is configured to only receive IPPFAX Jobs from
    outside its firewall, but receive IPP Jobs from inside its firewall, one or
    the other will be forced to supply an explicit (different) port?

    ISSUE 06: If an IPPFAX Receiver is configured for IPP only, should it still
    accept an IPPFAX job, rather than rejecting it, but perform it with IPP
    semantics? That is what an IPP/1.1 Printer would do that doesn't know about
    the IPPFAX spec and the IPP Sender won't make this mistake, since it MUST
    query to determine if the Receiver is currently accepting IPPFAX requests.

    ISSUE 07: OK to add the new 'client-error-missing-required-attribute'
    status code? The existing 'client-error-bad-request' status code isn't
    sufficient, since we want to return the missing attribute rather than
    indicate something wrong with what was submitted. Also the existing
    'client-error-forbidden' is too mysterious, since it suggests an
    authorization and/or authentication problem. In the past, missing REQUIRED
    attributes are developer errors, so that the 'client-error-bad-request' was
    sufficient. But this error can happen to a customer who has turned off IPP
    (or the implementation only supports IPPFAX semantics). This new status
    code can be used for other cases where 'client-error-bad-request' is used.

    ISSUE 08: How does coloring work when more than one UIF Profile is
    specified?

    ISSUE 09: Should we REQUIRE the Receiver to color attributes with the
    "ippfax-uif-profiles" supplied by the Sender in a Get-Printer-Attributes
    operation? If yes, should we REQUIRE the Sender to supply the
    "ippfax-uif-profiles" attribute in the Get-Printer-Attributes?

    ISSUE 10: Should we REQUIRE the Receiver to color attributes with the
    "document-format" supplied by the Sender in a Get-Printer-Attributes
    operation? If yes, should we REQUIRE the Sender to supply the
    "document-format" attribute in the Get-Printer-Attributes?

    ISSUE 11: OK to REQUIRE the Sender to query the "ippfax-versions-supported"
    Printer Description attribute, or is using Validate-Job sufficient if we
    change it from SHOULD to MUST? An IPP/1.1 Printer would return success,
    with the "ippfax-semantics" operation attribute in the Unsupported Group
    which the Sender could check for. What about an IPPFAX Receiver that is
    configured only for 'ipp'?

    ISSUE 12: OK to REQUIRE the Sender to query the
    "ippfax-semantics-supported" Printer Description attribute, or is using
    Validate-Job sufficient if we change it from SHOULD to MUST? An IPP/1.1
    Printer would return success, with the "ippfax-semantics" operation
    attribute in the Unsupported Group which the Sender could check for. What
    about an IPPFAX Receiver that is configured only for 'ipp'?

    ISSUE 13: Need to add some more UIF Profiles for color versus gray scale
    for C and L Profiles (same issue for UIF spec).

    ISSUE 14: OK that we got rid of the new 'octetString32k' attribute syntax
    and use existing IPP/1.1 attribute syntaxes, so that existing IPP systems
    can be used as gateways?

     ISSUE 15: are these additional capabilities restricted to the OPTIONAL
    capabilities in the UIF Profile according to the UIF spec ([14]), or MAY
    they include other capabilities as well?

    ISSUE 16: Should the UIF specification [14] add registered UIF Profile tags
    so that the entire minimum string becomes a single named token. Lloyd
    McIntyre thought this would be a good idea in order to shorten the strings
    and make the processing easier by the Sender.

    ISSUE 17: Should we add the new "ippfax-uif-profile" operation attribute to
    the Get-Printer-Attributes operation and then REQUIRE the Receiver to
    perform attribute coloring for the "ippfax-uif-profile" operation attribute?
    Then the Sender could determine the resolutions supported for a particular
    UIF Profile without having to do the CONNEG stuff?

    ISSUE 18: What restrictions on the vCard content do we need to make? vCard
    can have image, logos, sound!

    ISSUE 19: Denial of service problem: a Sender could bog down a Receiver Job
    with a huge amount of data which the Receiver is supposed to copy to the Job
    object

    ISSUE 20: What restrictions on the vCard content do we need to make? vCard
    can have image, logos, sound!

    ISSUE 21: Denial of service problem: a Sender could bog down a Receiver Job
    with a huge amount of data which the Receiver is supposed to copy to the Job
    object

    ISSUE 22: Did we agree to delete the ippfax-sender-uri (uri) operation/Job
    Description attribute in favor of depending on TLS authentication?

    ISSUE 23: SHOULD be using a client URL by preference and NOT a MAC address
    (generally totally unknown to an IPP client application). In any case the
    IEEE and IETF don't approve the use of MAC address for identifiers anymore
    except in EUI-64 format (an IEEE standard), which is the basis for canonical
    IPv6 self-configured global addresses. Ira will look up the RFC references
    later, if you want EUI-64

    ISSUE 24: Or should the spec be changed to REQUIRE the Sender to use
    Validate-Job? Currently the spec only RECOMMENDS using Validate-Job and
    REQUIRES that the Sender query a number of Printer Description attributes in
    order to submit a job the Receiver will accept.

    ISSUE 25 (for UIF document; see UIF ISSUE #4): Need to add the multi-valued
    profile parameter with 'uif-x' values to the image/tiff MIME Media Type
    registration and only have a single 'uif' value for the 'application'
    parameter (instead of 'uif-s', 'uif-c', 'uif-l', etc.).

    ISSUE 26: OK to REQUIRE the Sender to supply the "ippfax-uif-profiles" of
    the document being sent? What if the Sender didn't create the document?

    ISSUE 27: Need to fill in the TBD entries to indicate the IPPFAX semantics
    for the Job Template attributes.

    ISSUE 28: Are the entries in the Operations Conformance Table 6 correct?

    ISSUE 29: What does the 'tel' scheme do for IPPFAX?

    ISSUE 30: OK that we got rid of the new 'octetString32k' attribute syntax
    and use existing IPP/1.1 attribute syntaxes, so that existing IPP systems
    can be used as gateways?

    ISSUE 31: Is the description of this new
    'client-error-missing-required-attribute' (0x0419) status code sufficient?

    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 is an RFC, while version 2.1
    is not.

    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?

    3. IPPGET Delivery Method (<draft-ietf-ipp-notify-get-04.txt>), I posted
    Monday, 7/23, at:
    ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717-rev.pdf
    ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717.pdf

    ISSUE 01 (see section 12): Should we use application/multiplexed
    (draft-herriot-application-multiplexed-03.txt) which can chunk mime types
    using content lengths, instead of multi-part/related, which uses boundary
    strings?

    ISSUE 02: For Event Wait Mode, OK to make each successive response after
    the first a complete IPP response, instead of just the Event Notification
    Attributes Groups?

    Then each response looks like a complete response with its own status code.
    Also complete responses might be necessary on some other transport. Also we
    can move the "notify-interval" attribute back to the Operation Attributes
    Group where it belongs, since it applies to all events being returned in
    that response.

    ISSUE 03: OK to clarify that the Per-Job Subscription Object and the
    associated Job object MUST persist after the job completes (job completed,
    canceled, or aborted) in the Job Retention or Job History phases (see
    [RFC2911] section 4.3.7.2)?

    Otherwise, a Notification Recipient that is polling would not get the Event
    Notification, if it polled after the job completed, but before the Event
    Lease Time expired.

    ISSUE 04: OK to clarify that a client or a Printer MAY disconnect the
    underlying transport connect for any operation, including the Event No Wait
    Get-Notifications operation and the Event Wait Get-Notifications operation
    when the Printer isn't willing to honor the initial request or reneges in a
    later response?

    So a client could keep the connection open for multiple Event No Wait
    Get-Notifications. Before a Printer disconnects it needs to wait enough
    time to make sure that any IPP response has had time to get back to the
    client before disconnecting, otherwise the client might not see the
    response.

    ISSUE 05: OK to add 'successful-ok-events-complete' status code for a
    Get-Notifications response whether Event No Wait or Event Wait mode?

    Here is more detail:

    The Printer MUST return the 'successful-ok-events-complete' status code to
    indicate when this return is the last return for all Subscription objects
    that match the request, whether or not there are Event Notifications being
    returned. This condition occurs for Event Wait Mode Notification Recipients
    waiting for responses when the Subscription Object is: (1) canceled with a
    Cancel-Subscription operation, (2) deleted when the Per-Printer Subscription
    lease time expires, or (3) when the 'job-completed' event occurs for a
    Per-Job Subscription. This condition also occurs for a Get-Notifications
    request that a Notification Recipient makes after the job completes, but
    before the Event Lease Time expires.

    Here is a complete table of combinations of "notify-wait", "status-code",
    "notify-interval", and Event Notification Attributes Groups for
    Get-Notification initial (Wait and No Wait) Responses and subsequent Event
    Wait Mode Responses (which may be staying in Wait Mode or may be requesting
    the Notification Recipient to leave Wait Mode):
                                                              Event
      client sends: Printer returns: Notification
      "notify-wait" "status-code" "notify-get-interval" Attribute Groups
      ------------- ------------- --------------------- ----------------
    1.'false'/omitted 'successful-ok' MUST return N maybe
    2.'false'/omitted 'not-found' MUST NOT MUST NOT
    3.'false'/omitted 'busy' MUST return N MUST NOT
    4.'false'/omitted 'events-complete' MUST NOT 'job-completed'

    5. 'true' 'not-found' MUST NOT MUST NOT
    6. 'true' 'busy' MUST return N MUST NOT
    7. 'true' 'successful-ok' MUST NOT MUST
    8. 'true' 'successful-ok' MUST return N maybe
    9. 'true' 'events-complete' MUST NOT 'job-completed'
                                                              or maybe other
    Explanation:
    1-4: client requests Event No Wait
    5-9: client request Event No Wait
    2,5: Subscription object not found, or was canceled earlier; client should
    NOT try again.
    3,6: server busy, tells client to try later; client should try again in N
    seconds.
    4: client polled after job completed, but before Event Lease Time expired,
    and got the 'job-completed' event, so the client shouldn't bother trying
    again; client should NOT try again later.
    7: Printer returns one or more Event Notifications and is ok to stay in
    Event Wait Mode; the client waits for more.
    8: Printer wants to leave Event Wait mode. Can happen on the first
    response (with events) or happen on a subsequent response with or without
    Event Notifications; the client should try again in N seconds.
    9. Printer either (1) returns 'job-completed' event or (2) the Subscription
    Object was canceled by either a Cancel-Job or a Per-Printer Subscription
    expired without being renewed. For case (1), at least one event MUST be
    returned, while for case (2), it is unlikely that any Events are returned;
    the client should NOT try again.

    ISSUE 06: Section 12 says: "The Printer MAY chunk the responses, but this
    has no significance to the IPP semantics." Is this sufficient, or is
    HTTP/1.1 chunking REQUIRED in order to support the multi-part/related MIME
    type?

    ISSUE 07: For Event No Wait mode, should we add a way for the Notification
    Recipient to have the Printer filter out returning Event Notifications that
    the Notification Recipient has already received in order to reduce the
    duplicates (that will usually happen, else events will be lost)? Or should
    we just depend on most usage using Event Wait Mode, so that there aren't
    duplicates? It has been suggested on the mailing list that the Notification
    Recipient could supply pairs of the "notify-sequence-number" and
    "subscription-id" and the Printer would only return events with a higher
    sequence number.

    4. Drafts TIFF-FX Extension 1 and Schema Extension 1
    Lloyd McIntyre called our attention to last Monday, 7/23. As soon as it is
    approved we can add a Profile T (JBIG2) to our UIF document. Here it is
    important to send any comments to the Internet FAX DL (<ietf-fax@imc.org>)
    as well as the IPP FAX DL (<ifx@pwg.org). However, sending comments can be
    and should be done individually, but needs to be done before August 4 for
    the IETF meeting. Are there any comments from the WG to be sent?

    5. Review Schedule for these documents (all were supposed to be complete by
    June 2001 and the Bakeoff was supposed to be September 2001, January 2002
    was revised specification from the Bake Off and a possible Implementer's
    Guide was supposed to be finished January 2002.

    Tom



    This archive was generated by hypermail 2b29 : Fri Jul 27 2001 - 20:22:11 EDT