I've posted the .pdf and .doc versions of the 'collection' document that Bob
posted. The -rev.doc version has been updated in minors ways to add the IPP
boiler plate, use "IPP, not "IPP/1.1" in the title and header, add
references, and add clarifications and remove an issue. Please look over
for the IPP telecon, Wednesday, Feb 23, 2000. We think it is ready for IPP
WG Last Call.
ftp://ftp.pwg.org/pub/pwg/ipp/new_COL/ipp-collection-attr-syntax-000222.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_COL/ipp-collection-attr-syntax-000222.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_COL/ipp-collection-attr-syntax-000222-rev.
doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_COL/ipp-collection-attr-syntax-000222-rev.
pdf
The changes since the December 8, 1999 version, as agreed to at the New
Orleans meeting, are:
1. Added the "collection-syntax-recognized" (boolean) operation attribute
that clients MUST supply in all request if they can recognize a 'collection'
as a single attribute value in a response so that a Printer knows whether or
not it can safely return a collection value in a response.
2. Added the "collection-syntax-recognized" (boolean) Printer Description
attribute that Printers MUST support if they can recognize a 'collection' as
a single attribute value in a request so that a client knows whether or not
it can safely send a collection value in a request.
3. Clarified that the order of member attributes in a collection is not
significant and that a Printer MAY return the member attributes in a
different order from the way they were submitted by the client.
4. Added what each collection attribute definition must include.
5. Added various patterns that collection definitions may use for defaulting
and validation of collection values
6. Added the 'none' out-of-band value so that a client can indicate that no
collection value is being supplied and that the Printer MUST NOT supply a
default. The 'none' out of band value can be used with other attribute
syntaxes, but the 'collection' attribute syntax is the first that needs it.
7. Removed the sepCollection (0x38) attribute tag and the requiring the name
field of the endCollection (0x37) to be non-empty. These were to help with
the legacy issues which the "collection-syntax-recognized" (boolean)
operation attribute and the "collection-syntax-recognized" (boolean) Printer
Description solve much more completely. This removal also simplifies
implementation.
There is one issue:
ISSUE 01: If a Printer creates a notification subscription [ipp-ntfy] with a
request that does not include "collection-syntax-recognized" (boolean)
operation attribute with a value of 'true', then a Printer MUST NOT send a
collection in a Notification to a Notification Recipient?
This archive was generated by hypermail 2b29 : Tue Feb 22 2000 - 21:25:58 EST