Tom,
Issue 01: Mandate a single behavior. The Printer MUST reject the request
with the 'client-error-bad-request' status code when it encounters a
malformed (i.e. contains two or more member attributes with the same
attribute name) collection in a request.
Issue 02: I think encoding 2 is preferable. I would like to see an actual
encoding example rather than a "shorthand" overview.
Issue 03: The beginCollection and endCollection tags must be registered and
recorded the same way all other delimiter, value and syntax tags have been.
Pete
Peter Zehler
XEROX
Xerox Architecture Center
Email: Peter.Zehler@usa.xerox.com
Voice: (716) 265-8755
FAX: (716) 265-8792
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 139-05A
Webster NY, 14580-9701
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Friday, March 10, 2000 8:22 PM
To: ipp
Subject: IPP> COL - Updated 'collection' attribute syntax document down
loaded and sent as I-D 02
I've updated the collection specification as discussed at the recent
telecons and on the mailing list. This is mainly a collaboration between
Peter Zehler, Bob Herriot, and myself. We've each written parts of it. I
regret that it has been put together in such haste, so there are obvious
things that need work. I've sent this version as an Internet-Draft as well
(Internet-Draft are works in progress, so this one certainly fits that
description).
This version includes the three encoding solutions (1a, 1b, and 2) in it
that Bob sent out as a separate mail message. Please respond to that mail
message about which encoding technique to use for maximum compatibility with
IPP/1.1 recipients (clients and Printers) for comments on which encoding
technique to use.
Please send any comments about the rest of the document to the mailing list.
We'd also like to discuss this at the next IPP telecon, Wed, 3/15 as well.
ftp://ftp.pwg.org/pub/pwg/ipp/new_COL/draft-ietf-ipp-collection-02.txt
ftp://ftp.pwg.org/pub/pwg/ipp/new_COL/ipp-collection-attr-syntax-000309.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_COL/ipp-collection-attr-syntax-000309.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_COL/ipp-collection-attr-syntax-000309.txt
ftp://ftp.pwg.org/pub/pwg/ipp/new_COL/ipp-collection-attr-syntax-000309-rev.
doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_COL/ipp-collection-attr-syntax-000309-rev.
pdf
Regrettably, the page numbers stick out beyond column 72. A causality in
the rush.
Here is the Abstract:
This document specifies an OPTIONAL attribute syntax called
'collection' for use with the Internet Printing Protocol/1.0 (IPP) [RFC2565,
RFC2566], IPP/1.1 [ipp-mod, ipp-pro], and subsequent versions. A
'collection' is a container holding one or more named values, which are
called "member" attributes. A collection allows data to be grouped like a
PostScript dictionary or a Java Map.
Here is the Solution section 2:
The new mechanism is a new IPP attribute syntax called a 'collection'. As
such each collection value is a value of an attribute whose attribute syntax
type is defined to be a 'collection'. Such an attribute is called a
collection attribute. The name of the collection attribute serves to
identify the collection value in an operation request or response, as with
any attribute value.
The 'collection' attribute syntax is a container holding one or more named
values (i.e., attributes), which are called member attributes. Each
collection attribute definition document lists the mandatory and optional
member attributes of each collection value. A collection value is similar to
an IPP attribute group in a request or a response, such as the operation
attributes group. They both consist of a set of attributes.
As with any attribute syntax, the collection attribute definition document
specifies whether the attribute is single-value (collection) or multi-valued
(1setOf collection).
The name of each member attribute MUST be unique, but MAY be the same as the
name of a member attribute in another collection type and/or MAY be the same
as the name of an attribute that is not a member of a collection.. The
rules for naming member attributes are given in section 3.1.
Each member attribute can have any attribute syntax type, including
'collection', and can be either single-valued or multi-valued. The length
of a collection value is not limited. However, the length of each member
attribute MUST NOT exceed the limit of its attribute syntax.
The member attributes in a collection MAY be in any order in a request or
response. When a client sends a collection attribute to the Printer, the
order that the Printer stores the member attributes of the collection value
and the order returned in a response MAY be different from the order sent by
the client.
A collection value MUST NOT contains two or more member attributes with the
same attribute name. Such a collection is mal-formed. Clients MUST NOT
submit such malformed requests and Printers MUST NOT return such malformed
responses. If such a malformed request is submitted to a Printer, the
Printer MUST reject the request with the 'client-error-bad-request' status
code (see section 13.1.4.1)
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?
The other two issues are:
ISSUE 02: Which encoding do we want to use for collections, 1a, 1b, or 2?
ISSUE 03 - Since this is intended to be a standards track document, do we
also register the 'collection' attribute syntax codes (begCollection and
endCollection) with IANA?
Answer to the third issue is probably not, since it is intended to be a
standards track document.
Tom
This archive was generated by hypermail 2b29 : Tue Mar 14 2000 - 08:00:00 EST