IPP Mail Archive: IPP> ADM - Issue Resolutions from IPP WG m

IPP Mail Archive: IPP> ADM - Issue Resolutions from IPP WG m

IPP> ADM - Issue Resolutions from IPP WG meeting on 13 IPP documents

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Apr 12 2000 - 22:05:24 EDT

  • Next message: Marc Lev: "IPP> We pay cash, now!"

    Bob Herriot took the notes. I included the issue descriptions. This should
    help Lee with the official minutes as well.

    Tom

    Decisions from IPP WG meeting on 13 documents
    Tokyo, April 4-5, 2000

    1. ipp-job-prog-attr-000202.doc

    ISSUE 01 - Should we change the name from "sheet-collate" to
    "sheet-uncollate", since the absence of the attribute (and non-support of
    this attribute) is more likely to indicate collated sheets and so should be
    the 'false' value of the attribute, rather than the 'true' value?
    Issue 1 resolution: keep name as sheet-collate

    ISSUE 02 - Should we change the "sheet-collate" data type from 'boolean' to
    'type2 keyword' so that it could take on more values? This would also help
    with the name, say, "sheet-collation (type2 keyword) with values:
    'uncollated' and 'collated'. The "sheet-collation-supported" (1setOf type2
    keyword) would be more usual, than the unusual '1setOf boolean' also. In
    the future, we could define two collated values: 'multi-pass-collation' and
    'output-bin-collation' to indicate which form is requested and/or supported,
    since some Printers MAY want to support both.
    Issue 2 resolution: change value to keywords
     
    ISSUE 03 - If we change the attribute syntax to 'type2 keyword' should we
    have several values for the collated case now, i.e., define:
    'multi-pass-collation' and 'output-bin-collation', instead of just
    'collated'?
    Issue 3 resolution: make them be keywords, e.g. "collated" and "uncollated".
    Define no other values. The group doesn't understand the special values
    'multi-pass-collation' and 'output-bin-collation'.

    Issue (extra): Remove "sheet-collate" Job Template attribute from the "IPP:
    Production Printing Attributes - Set1" PWG specification and reference this
    document. Notification references the attributes in this document.

    ISSUE 04 - Regarding the "job-collation-type" (type2 enum): should the
    attribute syntax be 'type2 keyword' to go with IPP/1.1
    "multiple-document-handling(type2 keyword)" which have similar keyword
    values, instead of the Job MIB enum syntax?
    Issue 4 resolution: no, keep as enum

    ISSUE 05 - Or should we use the IPP out-of-band 'unknown' value (see
    [ipp-mod] section 4.1) instead of this unknown(2) enum Job Monitoring MIB
    value, i.e., "job-collation-type" (type2 keyword) instead of
    "job-collation-type" (type2 enum)?
    Issue 5 resolution: no, keep same Job MIB values

    2. ipp-notification-requirements-990811.doc

    ISSUE - Ok if there isn't a way for an End-User to submit an empty
    Per-Printer Subscription, in case such a Subscription slot is a scarce
    commodity, and then enable the Per-Printer Subscription when the data
    arrives and disable later without deleting the subscription?
    Issue resolution: remove the issue. Doesn't belong in requirements and is
    complicated

    ISSUE - Ok if spec doesn't have means for a Notification Recipient
    acknowledging receipt of a notification to the Notification Source?
    Issue: remove the issue but keep 13. It is vague enough and is a "may".

    3. ipp-not-spec-000308.doc

    change "ipp" scheme to "ippget".

    ISSUE 01 - Once a number of delivery solutions have been developed and
    evaluated, we may want to make one or several of them REQUIRED for
    implementation to ensure a minimum set of interoperability. Which one or
    ones should be REQUIRED?
    Issue 01 resolution: Remove issue and add a paragraph that says that one or
    more delivery methods will be required. The document on each delivery method
    states whether it is required.

    Move lines 628-638 (in pdf doc) into an informative annex so readers can
    determine notification delivery methods. Add a sentence referencing the
    annex.

    Lines 1022 and 1023: add a MUST for these items. Check the other items in
    this list too.

    4. ipp-notify-poll-000308.doc

    ISSUE 1: The 'ipp' is a convenient reuse of 'ipp', but does it imply the
    existence of a print service at each client that is not a reality?
    Issue 1 resolution: change scheme "ipp" to "ippget"

    Issue 2: Now that the Get-Notification operation does not affect the Event
    Notifications in the Printer, it should not require write access to access
    them.
    Issue 2 resolution: remove the issue. My change was OK.

    Issue 3: Is it possible for the Get-Notifications operation to have an
    option that causes it to delay completing its response? It would initially
    returns all existing Event Notifications. Then it would return additional
    notifications as they occur for some period of time. The client would
    receive these Event Notifications as they occur. The question is whether
    http servers or proxies would behave in this manner so that the client would
    get the Event Notifications without delay after they are sent by the http
    server? It has been suggested that the Printer send each burst of Event
    Notifications be in a separate message body where each message body is part
    of a multipart MIME content-type.
    Issue 3 resolution: remove issue and ask Harry to design and implement the
    "ipp-get-continuous" or whatever it is called.

    ISSUE 4: The "notification-recipient" option allows a client to group
    multiple Subscription-ids with a single URL. A client might decide to use
    the same URL for all subscriptions for a user, or it might have a separate
    URL for each client program. In addition a client might use an URL
    belonging to some other known user and let that user access Event
    Notifications using that URL. Is the above option useful?
    Issue 4 resolution: OK, but move the note to section 3 paragraph 2 where
    notification-recipient is further discussed. The explanation is currently
    unclear. Add note about friend's URL too.

    ISSUE 5: Is it a useful option to be able to leave out
    "notification-recipient", "subscription-ids", and "job-ids" that
    "notification-recipient" alone cannot do? Should this case be an error
    instead?
    Issue 5 resolution: require at least one of the 3 attributes and eliminate
    option for owner's event notifications.

    ISSUE 6: Is it better if "notification-recipient" is the only way to request
    Event Notification? If so, this behaves more like other notification
    delivery methods where a recipient receives those and only those events with
    its delivery URL. Furthermore, if there is a single mechanism of
    "notification-recipient" for a client to specify Event Notifications, a
    Printer can better optimize event-leases because it knows which events will
    be accessed together. If client can specify subscription-ids, each request
    can contain a different mix of subscription-ids.
    Issue 6 resolution: remove issue for now. I hope it doesn't make for complex
    implementations.

    5. ipp-notify-mailto-000309.doc

    Change SMPT to SMTP

    ISSUE 01: Is this SMTP terminology correct?
    Issue 1 resolution: issue is valid. Look up typical wording in other
    documents. The Printer does have to speak SMTP protocol to specified
    notification recipient.

    ISSUE 02: Is it a good idea to list each Subscription object attribute in
    this spec with the applicability to this delivery method? If yes, should
    all delivery method specs also do it this way?
    Issue 2 resolution: remove issue. Leave the rule as "should" include all
    which is in the "spec" document.

    ISSUE 03 - What should we say about any mailto parameters, if any? For
    example, if you want to send over secure mail, etc.
    Issue 3 resolution: no parameters for now. Wait until there is a proven
    need.

    ISSUE 04 - Do we want to define any IPP-specific mailto parameters to this
    document?
    Issue 4 resolution: seems like the same issue as issue 3 and the answer is
    the same.

    ISSUE 05: Ok that we made "subscriber-user-name" be REQUIRED for the
    Printer to support and indicate that the client MUST supply the
    "requester-user-name" operation attribute when the delivery method is
    'mailto:', in case the Printer does not have a more authenticated printable
    name?
    Issue 5 resolution: The subscriber-user-name is already defined as required
    in the spec document. Making the requesting-user-name required doesn't solve
    the problem because it is the email address that we need. Should we require
    the email address of the person doing the subscription. The subscriber user
    name is not an email address - it is a name. We want an email address for
    reporting errors - this feature is RECOMMENDED. The from in the email
    should be the Printer. Check with Ned Freed on best way to do this.

    ISSUE 06: What if "notify-format" is 'text/plain; charset=utf-8', does that
    have to be sent as a mail attachment, since it isn't 'text/plain' which
    assumes charset=us-ascii, or can it be sent as the body of the mail message
    properly identified as 'text/plain; charset=us-ascii'?
    Issue 6 resolution: need further research on what works with email Ask Ned
    Freed. He talks about this issue in RFC 2045.

    ISSUE 07 - Is there any way that a Notification Recipient could reply to the
    message in such a way as to cancel the subscription and thereby solve the
    spam problem?
    Issue 7 resolution: No. This mechanism is more than we need.

    Another issue: Section 10, remove or perhaps reword the last paragraph. It
    compare mailto with other notification delivery methods that have better
    security. Why point out why mailto is worse?

    6. draft-ietf-indp-000229.doc

    not reviewed. No one present with enough information.

    7. draft-ietf-indp-method-000229.doc

    Fix headers/footers. The date and title are wrong.

    ISSUE 01 - Should there be an Unsupported Attributes group to return
    attributes that are not supported to the client?
    Issue 1 resolution: No need to return unsupported attributes. Printer would
    likely ignore them.

    ISSUE 02 - Use the same status code space as IPP, namely:
    "successful" - 0x0000 to 0x00FF
    "informational" - 0x0100 to 0x01FF
    "redirection" - 0x0200 to 0x02FF
    "client-error" - 0x0400 to 0x04FF
    "server-error" - 0x0500 to 0x05FF
    Issue 2 resolution: It seems to be overkill to have a separate status per
    event notification and more than one failure code. One status code per
    operation is sufficient and a single failure is sufficient. It doesn't seem
    that a Printer would do anything useful with a status per event notification
    or a failure that is either a bad subscription id or bad-response. In all
    cases the Printer doesn't send the events again.

    8. ipp-job-printer-set-ops-000308.doc

    looks OK

    9. ipp-ops-set2-000203.doc

    line 34 change 7 to 5

    Review on mailing list to see if some operations should be pruned.

    10. pwg-ipp-prod-print-set1-000207.doc

    Issue 01 resolution: remove sheets-collated because it is in another
    document.

    Issue 04 resolution: already moved none to collection document.

    11. ipp-collection-attr-syntax-000331.doc

    ISSUE 01: In attribute groups [ipp-mod] allows a Printer either (1) to
    reject a request with duplicate named attributes OR (2) to choose exactly
    one of the attributes as the one to be used. Should we REQUIRE the Printer
    to reject duplicate named attributes in a collection value as stated above
    or allow the Printer to choose one member attribute as a second alternative
    as we do with attribute groups?
    Issue 1 resolution: put in model doc language that allows printer to
    reject, take last, take first, etc.

    ISSUE 02 - The example contains a 1setOf collection and a nested collection,
    but does not contain a 1setOf member attribute. Should there be four
    separate examples that show a simple collection, a 1setOf member attribute,
    a 1setOf collection, and a nested collection?
    Issue 2 resolution: Yes do all possible examples

    ISSUE 03 - Since this is intended to be a standards track document, do we
    also register the attribute syntax with IANA?
    Issue 3 resolution: yes, register with IANA.

    Add examples that show all combination and in the tabular form that I did in
    the email and in the protocol document format The former is easier to read.
    Add color to show nesting.

    12. pwg-ipp-exceptions-model-000131.doc

    Add document copies attributes

    13. ipp-implementers-guide-990927.doc

    Add annex which describes how to register a new MIME type for mimeMediaType



    This archive was generated by hypermail 2b29 : Wed Apr 12 2000 - 22:12:10 EDT