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