draft-ietf-ipp-collection-01.txt   draft-ietf-ipp-collection-02.txt 
INTERNET-DRAFT Roger deBry INTERNET-DRAFT Roger deBry
<draft-ietf-ipp-collection-01.txt> Utah Valley State College <draft-ietf-ipp-collection-02.txt> Utah Valley State College
T. Hastings T. Hastings
Xerox Corporation Xerox Corporation
R. Herriot R. Herriot
Xerox Corporation Xerox Corporation
February 22, 2000 K. Ocke
Xerox Corporation
P. Zehler
Xerox Corporation
March 9, 2000
Internet Printing Protocol: Internet Printing Protocol (IPP):
The 'collection' attribute syntax The 'collection' attribute syntax
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
Status of this Memo: Status of this Memo:
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC2026]. Internet-Drafts are working provisions of Section 10 of [RFC2026]. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
skipping to change at page 2, line 5 skipping to change at page 1, line 48
Abstract Abstract
This document specifies an OPTIONAL attribute syntax called This document specifies an OPTIONAL attribute syntax called
'collection' for use with the Internet Printing Protocol/1.0 'collection' for use with the Internet Printing Protocol/1.0
(IPP) [RFC2565, RFC2566], IPP/1.1 [ipp-mod, ipp-pro], and (IPP) [RFC2565, RFC2566], IPP/1.1 [ipp-mod, ipp-pro], and
subsequent versions. A 'collection' is a container holding one or subsequent versions. A 'collection' is a container holding one or
more named values, which are called "member" attributes. A more named values, which are called "member" attributes. A
collection allows data to be grouped like a PostScript dictionary collection allows data to be grouped like a PostScript dictionary
or a Java Map. or a Java Map.
[Expires: August 22, 2000] There are 4 issues in the document.
[Expires: September 9, 2000]
The full set of IPP documents includes: The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567] Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [RFC2568] Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics (this document) Internet Printing Protocol/1.1: Model and Semantics (this document)
Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO] Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO]
Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG] Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
Mapping between LPD and IPP Protocols [RFC2569] Mapping between LPD and IPP Protocols [RFC2569]
skipping to change at page 3, line 5 skipping to change at page 3, line 5
is intended to help them understand IPP/1.1 and some of the is intended to help them understand IPP/1.1 and some of the
considerations that may assist them in the design of their client and/or considerations that may assist them in the design of their client and/or
IPP object implementations. For example, a typical order of processing IPP object implementations. For example, a typical order of processing
requests is given, including error checking. Motivation for some of the requests is given, including error checking. Motivation for some of the
specification decisions is also included. specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice The "Mapping between LPD and IPP Protocols" document gives some advice
to implementers of gateways between IPP and LPD (Line Printer Daemon) to implementers of gateways between IPP and LPD (Line Printer Daemon)
implementations. implementations.
[Expires: August 22, 2000] [Expires: September 9, 2000]
Table of Contents Table of Contents
1 Problem Statement.................................................4 1 Problem Statement.................................................4
2 Solution..........................................................4 2 Solution..........................................................4
3 Definition of a Collection Type...................................5 3 Definition of a Collection Attribute..............................5
4 Order of Member Attributes........................................6 3.1 Member Attribute Naming Rules..................................5
5 New Operation Attribute...........................................6 3.2 Remaining rules for a collection attribute definition..........6
5.1collection-syntax-recognized (boolean)...........................6 3.3 Nested Collections.............................................8
6 New Printer Attribute.............................................7 3.4 Collection Attributes as Operation Attributes..................9
6.1collection-syntax-recognized (boolean)...........................7 3.5 Collections as Job Template Attributes.........................9
7 New Out-of-band value.............................................7 3.6 Collections and Get-Printer-Attributes and Get-Job-Attributes
7.1'none'...........................................................7 operations.........................................................10
8 Unsupported Values................................................7 4 New Out-of-band value............................................11
9 Encoding..........................................................8 4.1 'none'........................................................11
10 Legacy issues.....................................................9 5 Unsupported Values...............................................12
11 IANA Considerations..............................................10 6 Sample specification.............................................12
12 Internationalization Considerations..............................10 7 Encoding.........................................................13
13 Security Considerations..........................................10 7.1 encoding of a collection (using solution 1a)..................17
14 References.......................................................10 7.2 Sample Encoding (using solution 1a)...........................19
15 Author's Addresses...............................................11 7.3 1setOf Collection encoding (using solution 1a)................20
16 APPENDIX A: Example of collection usage..........................12 7.4 Sample 1setOf Collection encoding (using solution 1a).........21
16.1"job-notify" Operation attribute..............................12 8 Legacy issues....................................................23
17 Appendix B: Full Copyright Statement.............................12 9 IANA Considerations..............................................24
10 Internationalization Considerations..............................24
11 Security Considerations..........................................24
12 References.......................................................24
13 Author's Addresses...............................................25
14 Appendix A: Full Copyright Statement.............................26
[Expires: August 22, 2000] [Expires: September 9, 2000]
1 Problem Statement 1 Problem Statement
IPP supports most of the common data structures that are available in The IPP Model and Semantics [ipp-mod] supports most of the common data
programming languages. It lacks a mechanism for grouping several values structures that are available in programming languages. It lacks a
of different types. The Java language uses the Map to solve this mechanism for grouping several attributes of different types. The Java
problem and PostScript has a dictionary. language uses the Map to solve this problem and PostScript has a
dictionary. The new mechanism for grouping attributes together must
allow for optional members and subsequent extension of the collection.
The mechanism must be encoded in a manner consistent with existing 1.0
and 1.1 parsing rules (see [ipp-pro]). Current 1.0 and 1.1 parsers that
don't support collections should not confuse collections they receive
with attributes that they do support.
2 Solution 2 Solution
The IPP 'collection' is a container holding one or more named values The new mechanism is a new IPP attribute syntax called a 'collection'.
(i.e. attributes), which are called member attributes. A collection also As such each collection value is a value of an attribute whose attribute
has a type name, which identifies the expected member attributes, as syntax type is defined to be a 'collection'. Such an attribute is
does a subclass of a Java Map. A collection value is similar to a group, called a collection attribute. The name of the collection attribute
such as an operation group. They both consist of a set of attributes. serves to identify the collection value in an operation request or
response, as with any attribute value.
The name of each member attribute MUST be unique within a collection, The 'collection' attribute syntax is a container holding one or more
but MAY be the same as the name of a member attribute in another named values (i.e., attributes), which are called member attributes.
collection type and/or MAY be the same as the name of an attribute that Each collection attribute definition document lists the mandatory and
is not a member of a collection. 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.
A client or Printer is said to "recognize" collections as a single As with any attribute syntax, the collection attribute definition
attribute value if it can determine the beginning and end of a document specifies whether the attribute is single-value (collection) or
collection value and if it can distinguish attributes within the multi-valued (1setOf collection).
collection from attributes outside of the collection. In order to
support legacy IPP implementations, a client MUST indicate that it
"recognizes" collections by including the operation attribute
"collection-syntax-recognized" with the value of 'true' in each request.
A printer MUST indicate that it "recognizes" collections by supporting
the attribute "collection-syntax-recognized" with the value of 'true'.
The fact that a Printer recognizes collections does not require the The name of each member attribute MUST be unique, but MAY be the same as
printer to support collection values of attributes that are defined to the name of a member attribute in another collection type and/or MAY be
have values of collections and other attribute syntaxes. For example, the same as the name of an attribute that is not a member of a
if an attribute is defined to have the attribute syntax: (type3 keyword collection.. The rules for naming member attributes are given in
| name | collection), a Printer that recognizes collections MAY support section 3.1.
only keyword values of such an attribute.
Each member attribute can have any attribute syntax type, including Each member attribute can have any attribute syntax type, including
'collection', and can be either single-valued or multi-valued. The 'collection', and can be either single-valued or multi-valued. The
length of a collection value is not limited. However, the length of each length of a collection value is not limited. However, the length of each
member attribute MUST NOT exceed the limit of its attribute syntax. member attribute MUST NOT exceed the limit of its attribute syntax.
The member attributes in a collection can be in any order. When a client The member attributes in a collection MAY be in any order in a request
sends the Printer a collection, the order that the Printer stores the or response. When a client sends a collection attribute to the Printer,
value and the order returned in a response MAY be different from the
order sent by the client.
If a collection contains two or more member attributes with the same [Expires: September 9, 2000]
attribute name, the collection is not well formed. The receiver of such
[Expires: August 22, 2000] 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 MAY either treat the collection as a bad value or ignore A collection value MUST NOT contains two or more member attributes with
all but one of the identically named member attributes. 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)
3 Definition of a Collection Type 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?
When a specification defines an attribute "xxx" whose syntax type is 3 Definition of a Collection Attribute
'collection' or '1setOf collection', it must define following aspects of
the attribute.
1. The name of the attribute "xxx" This section describes the requirements for any collection attribute
definition.
2. Its syntax type, which includes a collection syntax-type 3.1 Member Attribute Naming Rules
3. Its default-value is specified by Each collection attribute MUST have a unique name within the scope in
which the collection attribute occurs. If the collection attribute
occurs as a member of a request or response attribute group, it MUST be
unique within that group, same as for any other attribute. If a
collection attribute occurs as a member attribute of another collection,
the collection attribute MUST have a unique name within that collection
value, same as for any other attribute.
a)the attribute's definition Each member attribute in a collection value MUST have unique name within
that collection value. Member attribute names MAY be reused between
different collection attributes. An example is the "media" attribute
which MAY be used as a job template attribute (see [ipp-mod]) and in a
collection. All attribute names that are reused MUST have an identical
syntax. All attribute names that are reused MUST have a similar
semantics. The semantic difference MUST be limited to boundary
conditions and constraints placed on the reused attributes. All
attributes that are not reused from elsewhere in the IPP model MUST have
a globally unique name.
b)an attribute, such as "xxx-default", which may have a collection Assume that it is desirable to extend IPP by adding a Job Template
value attribute that allows the client to select the media by its properties,
e.g., weight, color, size, etc., instead of by name as the "media (type3
keyword | name) Job Template attribute in IPP/1.1 (see [ipp-mod]). The
first rule is that the existing attribute MUST NOT be extended by adding
the 'collection' attribute syntax to the existing "media" attribute.
That would cause too many interoperability problems and complicates the
4. Its supported values, which may be specified by one of: [Expires: September 9, 2000]
a)the attribute's definition validation and defaulting rules as well. Instead, a new attribute will
be defined with a suffix of "-col" (for collection), e.g., "media-col"
(collection).
b)a boolean attribute, such as "xxx-supported", which is true if For a second example, suppose it is desirable to extend IPP by allowing
the attribute is supported. The supported values are specified the client to select the media for the job start sheet. Again, this
by the attribute's definition which specifies the supported would not be done by adding the 'collection' attribute syntax to the
values for each member of a collection or the "yyy-supported" existing "job-sheets" (type2 keyword | name) Job Template attribute.
that specifies the value supported for the "yyy" member Instead, a new "job-sheet-col" (collection) Job Template attribute MUST
attribute. be introduced. The member of the "job-sheet-col" collection might be:
c)an attribute, such as "xxx-supported", which contains the "job-sheet-format" (type3 keyword | name)
explicit collection values and other values supported. "media" (type3 keyword | name)
5. the name of the collection type, whose characters are the same as if any of the "media-supported" (1setOf (type3 keyword | name)) Printer
those for a keyword. attribute values could be specified for job sheets. The reason that the
"job-sheet-format" member attribute isn't named simply, "job-sheet", is
because its values only indicate the format, and don't imply any media,
while the "job-sheets" (type2 keyword | name) Job Template attribute do
imply a media. This example illustrates when a member attribute can be
the same as another attribute (in this case a Job Template attribute)
and when the member attribute MUST have a different name.
6. the following information about each "yyy" member attribute: If the definers of the "job-sheet-col" (collection) attribute intended
that the System Administrator be allowed to have a different set of
media values for job sheets than documents, then the definition document
for the "job-sheet-col" collection attribute would have the following
member attributes instead:
a)its name, which is a keyword like all attributes. It must be "job-sheet-format" (type3 keyword | name)
unique within the collection type. "job-sheet-media" (type3 keyword | name)
b)its syntax type, which may be any IPP syntax type, including Then the supported values would be include in a separate "job-sheet-
'collection'. If the attribute syntax type starts with "1setOf", media-supported" (1setOf (type3 keyword | name)) Printer attribute.
the member attribute is multi-valued.
c)its supported values, either enumerated explicitly or specified 3.2 Remaining rules for a collection attribute definition
by the values of a referenced attribute which may be specified
by either:
@ the attribute's definition When a specification document defines an "xxx" collection attribute,
i.e., an attribute whose attribute syntax type is 'collection' or
'1setOf collection'; the definition document MUST include the following
aspects of the attribute semantics. Suppose the "xxx" collection
attribute contains an "aaa" member attribute. A simplified example of a
collection specification is given in section 6
[Expires: August 22, 2000] 1. The name of the collection attribute MUST be specified. (e.g.
@ an attribute, such as "yyy-supported", which contains the "xxx")
explicit values supported. The "yyy-supported" attribute is
a Printer attribute and not in a collection. For example,
if a collection contains the "media" attribute and its
supported values are specified by the "media-supported"
attribute, the "media-supported" attribute is the same
Printer attribute that the "media" attribute uses.
d)whether "yyy" MUST be or MAY be supplied by a client in a 2. The collection attribute syntax MUST be of type 'collection' or
request. '1setOf collection'.
e)the default value of "yyy" if it is OPTIONAL for a client to 3. The context of the collection attribute MUST be specified, i.e.,
supply the "yyy" attribute in a request. The default value is whether the attribute is an operation attribute, a Job Template
specified by either: attribute, a Job Description attribute, a Printer Description
[Expires: September 9, 2000]
attribute, a member attribute of a particular collection attribute,
etc.
4. The member attributes MUST be defined. For each member attribute
the definition document MUST provide the following:
a)The member attribute's name, "aaa", MUST either (1) reuse the
attribute name of another attribute if the member attribute
shares the syntax and semantics with the other attribute or (2)
be unique across the entire IPP attribute name space
b)Whether the member attribute is REQUIRED or OPTIONAL for the
Printer to support
c)Whether the member attribute is REQUIRED or OPTIONAL for the
client to supply in a request
d)The member attribute's syntax type, which can be any attribute
syntax, including '1setOf X', 'collection', and '1setOf
collection'. If this attribute name is the same as another
attribute (case of option a-1 above), it MUST have the same
attribute syntax, including cardinality (1setOf or not).
e)The semantics of the "aaa" member attribute. The semantic
definition MUST include a description of any constraint or
boundary conditions the member attribute places on the
associated attribute, especially if the attribute is the same as
another attribute used in a different context (case of option a-
1 above)
f)the supported values for the "aaa" member attribute, either
enumerated explicitly or specified by the values of a referenced
attribute which may be specified by either:
@ the attribute's definition @ the attribute's definition
@ an attribute, such as "yyy-default", which may have a @ a Printer attribute, such as "aaa-supported", which
contains the explicit values supported. The "aaa-supported"
attribute is a Printer attribute and not in a collection.
For example, if a collection contains the "media" attribute
and its supported values are specified by the "media-
supported" attribute, the "media-supported" attribute is
the same Printer attribute that the "media" attribute uses.
g)the default value of "aaa" member attribute if it is OPTIONAL
for a client to supply the "aaa" member attribute in a request.
The default value is specified by either:
@ the attribute's definition
@ a Printer attribute, such as "aaa-default", which may have
a collection value
[Expires: September 9, 2000]
@ or an implementation defined algorithm that takes into
account the values of the other member attributes of the
collection value collection value
f)whether "yyy" MUST be or MAY be supported by the printer. h)Depending on the collection attributes context, it MUST follow
the additional rules specified below for the various contexts.
g)the semantics of "yyy". 3.3 Nested Collections
4 Order of Member Attributes A member attribute may have a syntax type of 'collection' or '1setOf
collection'. The following example assumes a "yyy" collection attribute
is a member attribute of the preceding "xxx" collection attribute. The
"yyy" collection attribute contains "bbb" member attribute. The
definition document for the nested collection MUST include:
The member attributes of a collection value are unordered. A Printer 1.The name of the collection attribute, e.g., "yyy"
and a client MUST accept member attributes of a collection in any order.
Therefore, a Printer and a client MAY send the member attributes of a
collection value in any order. A Printer NEED NOT return member
attributes to a client in the order received from a client.
5 New Operation Attribute 2.The collection attribute syntax MUST be of type 'collection' or
'1setOf collection'
5.1 collection-syntax-recognized (boolean) 3.The member attributes MUST be defined. For each member attribute the
definition document MUST provide the following:
A client MUST include this operation attribute with a value of 'true' in a) The member attribute's name, "bbb", MUST either (1) reuse the
each request if it recognizes the collection-syntax. If a client does attribute name of another attribute if the member attribute shares
not include this operation attribute or its value is not 'true' in a the syntax and semantics with the other attribute or (2) be unique
request, then a Printer MUST NOT return a collection in a response. across the entire IPP attribute name space
ISSUE 01: If a Printer creates a notification subscription [ipp-ntfy] b) Whether the member attribute is REQUIRED or OPTIONAL for the
with a request that does not include "collection-syntax-recognized" Printer to support
(boolean) operation attribute with a value of 'true', then a Printer
MUST NOT send a collection in a Notification to a Notification
Recipient?
[Expires: August 22, 2000] c) Whether the member attribute is REQUIRED or OPTIONAL for the client
to supply in a request
6 New Printer Attribute d) The member attribute's syntax type, which can be any attribute
syntax, including '1setOf X', 'collection', and '1setOf
collection'. If this attribute name is the same as another
attribute (case of option a-1 above), it MUST have the same
attribute syntax, including cardinality (1setOf or not)
6.1 collection-syntax-recognized (boolean) e) The semantics of the member attribute. The semantic definition MUST
include a description of any constraint or boundary conditions the
member attribute places on the associated attribute, especially if
the attribute is the same as another attribute used in a different
context (case of option a-1 above)
A Printer MUST support this attribute with a value of 'true' if it f)
recognizes the collection-syntax. If a Printer does not support this
attribute or its value is not 'true', then a client MUST NOT send a
collection in a request.
7 New Out-of-band value g) Depending on the collection attributes context, it MUST follow the
additional rules specified below for the various contexts.
7.1 'none' [Expires: September 9, 2000]
3.4 Collection Attributes as Operation Attributes
The definition documents that define a collection attribute for use as
an operation attribute MUST follow these additional rules:
a)Define in which operation requests the collection attribute is
intended to be used.
b)Define in which operation responses the collection attribute is
intended to be used.
3.5 Collections as Job Template Attributes
The definition documents for collection attributes that are specified to
be Job Template attributes (see [ipp-mod] section 4.2) MUST have
associated printer attributes with suffixes of "-supported" and "-
default" (or indicate that there is no "-default"), just as for any Job
Template attribute. Certain Job Template collection attributes also
have an associated Printer attribute with "-ready" (for example, see the
"media-ready" attribute in [ipp-mod]). Furthermore member attributes of
job template attributes are addressed using the same suffix convention.
See also section 3.6 on the interaction of collections and the Get-
Printer-Attributes and Get-Jobs-Attributes.
For the following rules assume the "xxx" (collection) example from
section 3.2 is a job template attribute.
1)There MUST be two associated printer attributes. The attributes are
"xxx-supported" and "xxx-default"
2)The "xxx-default" is a collection with a syntax identical to the
"xxx" specification in section 3.2 .
@ Each member attribute has the same name as in the "xxx"
definition.
@ A Get-Printer-Attributes operation MUST return the "xxx-default"
(collection) Printer attribute and all the member attributes.
Any default values that have been set MUST be returned. Any
default values that have not been set MUST return an out of band
attribute of 'no-value'.
3.If the definition of the collection does not mention an "xxx-ready"
attribute than it is assumed that one is not defined, though
implementer's are free to support an "xxx-ready" as an extension.
4.The collection attribute definition document MUST define an "xxx-
supported" attribute with either a syntax of '1setOf type2 keyword'
or '1setOf collection':
[Expires: September 9, 2000]
@ If the definition uses the '1setOf type2 keyword' attribute
syntax, it MUST be the attribute keyword names of all of the
member attributes that the Printer implementation supports in a
Job Creation operation. Furthermore, the definition MUST
include corresponding definitions of each of the "aaa-supported"
attributes that correspond to each "aaa" member attribute. Then
a client can determine the supported values of each member
attribute in the Job Template collection attribute
@ If the definition uses the '1setOf collection' attribute syntax,
then the values are the supported instances of the "xxx"
(collection) attribute that a client can supply in a Job
Creation operation. It is expected that this second approach
will be used for small collections whether the number of
possible collection values is small. For example, a "media-
size" (collection) member attribute in which the member
attributes are "x-dimension" (integer) and "y-dimension"
(integer). The pairs of integers are just like keywords as far
as the client localization is concerned, except that if the
client doesn't recognize a size pair of numbers, it can display
the numbers.
a) The keywords returned lists all the contained member attribute
names. This example would return the "aaa" keyword.
b) The list is recursive and lists all the member attributes of the
contained collections. In section 3.3 the printer would return
"aaa" and "bbb" for collection "xxx"
c) The encoding convention allows the reconstruction of the collection
structure. The will allow the client to reconstruct the
collections. The client would know that "aaa" is a member of
collection "xxx". It can also be derived that collection "bbb" is
a member of collection "yyy". See section 7 for more information
on encoding.
d) To obtain the supported values for any member attribute a client
performs a Get-Printer-Attributes operation explicitly requesting
the member attribute name with the suffix "supported". If a member
attribute is itself a collection rule 4 above applies to member
attribute.
3.6 Collections and Get-Printer-Attributes and Get-Job-Attributes
operations
The behavior of collections for "job-description" and "printer-
description" is similar to any other attribute. Simple attributes
return the attribute and its value. For a collection, the collection
and its entire member attributes and their values are returned. This
includes any containing collections, its member attributes and their
values. The same logic applies for the "-default" and "-ready" printer
attribute associated with a job-template attributes.
[Expires: September 9, 2000]
Whether the Printer applies individual member attributes independently
or takes into account the member attributes supplied by the client in
the collection, depends on implementation. Therefore, a client SHOULD
query the Printer's "xxx-default" (collection) attribute, allow the user
to make any changes, and then submit the entire collection to the
Printer. Then the variability in defaulting between different
implementations will not cause the user to get unexpected results.
The semantics for "-supported" is different for a collection. Here the
focus is on the member attributes that the collection supports. This
solution allows for extension of collections and allowing the member
attributes of a collection to vary (i.e. mandatory and optional member
attributes). Once a client determines what member attributes are
supported in a collection a subsequent request can be constructed to
determine the supported values for the member attributes.
Another advantage of that the behavior of the "-supported" printer
collection attribute is limiting the amount of data that is returned on
general queries. A 'get-printer-attributes' that returns all the
attributes of a printer will not have to return what may turn out to be
extensive lists of "-supported" attribute values. An example might be
"media-col" that could be a representation for media using a collection
that goes beyond the information currently provided by the job-template
attribute "media". The "media-col" could now be used to represent a
job's media, insert sheets and inserted tab sheets. An IPP Printer
implementation would return the member attributes for each of the "-
supported" collections.
4 New Out-of-band value
4.1 'none'
'none' The specified Job Template attribute in the request MUST 'none' The specified Job Template attribute in the request MUST
NOT be applied to the job. Specifically, this value NOT be applied to the job. Specifically, this value
overrides the Printer's "xxx-default" attribute value for overrides the Printer's "xxx-default" attribute value for
the Job Template attribute, if one exists. the Job Template attribute, if one exists.
This "out-of-band" value allows a client to specify "turn-off" a feature This "out-of-band" value allows a client to specify "turn-off" a feature
that is specified by an attribute whose value is a collection. Because a that is specified by an attribute whose value is a collection. Because a
client specifies a value, the Printer uses the client-specified value client specifies a value, the Printer uses the client-specified value
and not the Printer's default value. and not the Printer's default value.
If a Printer supports the use of the 'collection' attribute syntax for If a Printer supports the use of the 'collection' attribute syntax for
an attribute, a Printer MUST support the use of the "out-of-band" value an attribute, a Printer MUST support the use of the "out-of-band" value
'none'. 'none'.
A Printer MUST support the "out-of-band" value 'none' as the value for A Printer MUST support the "out-of-band" value 'none' as the value for
an attribute "xxx" if: an attribute "xxx" if:
[Expires: September 9, 2000]
@ the definition of the attribute specifies 'none' MUST be @ the definition of the attribute specifies 'none' MUST be
supported AND supported AND
@ the definition of the attribute specifies 'none' MAY be @ the definition of the attribute specifies 'none' MAY be
supported and it is a value of the attribute "xxx-supported". supported and it is a value of the attribute "xxx-supported".
8 Unsupported Values 5 Unsupported Values
The rules for returning an unsupported collection attribute are an The rules for returning an unsupported collection attribute are an
extension to the current rules. extension to the current rules.
If the entire collection attribute is unsupported, then the Printer
returns just the collection attribute name with the 'unsupported'
out-of-band value (see the beginning of [ipp-mod] section 4.1) in the
Unsupported Attributes Group.
If a collection contains unrecognized, unsupported member attributes If a collection contains unrecognized, unsupported member attributes
and/or conflicting values, the attribute returned in the Unsupported and/or conflicting values, the attribute returned in the Unsupported
Group is a collection containing the unrecognized, unsupported member Group is a collection containing the unrecognized, unsupported member
attributes, and/or conflicting values. The unrecognized member attributes, and/or conflicting values. The unrecognized member
attributes have an out-of-band value of 'unsupported' (see the attributes have an out-of-band value of 'unsupported' (see the
beginning of [ipp-mod] section 4.1). The unsupported member beginning of [ipp-mod] section 4.1). The unsupported member
attributes and conflicting values have their unsupported values. attributes and conflicting values have their unsupported or
conflicting values.
[Expires: August 22, 2000] 6 Sample specification
9 Encoding This example is for a collection called "media-col". The "media-col"
attribute is a job template attribute. This collection is simplified
and fictitious and is used for illustrative purposes only.
This section defines the encoding of a collection syntax type. A Name: media-col
collection is encoded by using three new tags:
Syntax: collection
Member Attributes:
Name: "media-color"
Syntax: type3 keyword | name
Mandatory
Semantics: This attribute identifies the color of the media. Valid
values are "red" "white" and "blue"
"media-color-supported" syntax: 1setOf (type2 keyword | name)
Name: "media-size"
[Expires: September 9, 2000]
Syntax: collection
Member Attributes:
Name: "x-dimension"
Syntax: integer
Mandatory
Semantics: This attribute identifies length of the media in
inches. Valid values are any integer though in practice
implementation will constrain the range.
x-supported syntax: rangeOfInteger
Name: "y-dimension"
Syntax: integer
Mandatory
Semantics: This attribute identifies the width of the media in
inches. Valid values are any integer though in practice
implementation will constrain the range.
y-supported syntax: rangeOfInteger
Name: name
Syntax: See job template attribute "media"
Optional
Semantics: See job template attribute "media". Additional
restrictions on "media" in this collection are that the "media"
value must be valid based on the size and color. When invalid
names are given based on the size or color, the size or color value
takes precedence.
Supported values identical to job template attribute "media-
supported".
7 Encoding
This section is still under construction.
We are now down to considering two encodings for collections. The goals
of the encoding are:
[Expires: September 9, 2000]
a) must be simple
b) a legacy receiver must correctly ignore a collection value and not
incorrectly decode part of a collection as a legitimate attribute.
c) it parses an attributes with collection values as a single unknown
attribute rather than as many unknown attributes.
The two encodings are:
1) encode attributes within collections in the same way as
attributes outside of collections, but encode each attribute name
in a collection so that its name cannot be the same as an attribute
name outside of a collection. We have considered two solutions for
encoding attribute names.
a) add a prefix to each collection member attribute name where
the prefix is the (outer) attribute's name following by a dot
("."). Nested collections have extra levels of dotted names.
For example, the "media-size" attribute in "media-col" is
encoded as "media-col.media-size" and the "x" attribute in
"media-size" which is inside "media" is encoded as "media-
col.media-size.x". The outer attribute name is the "name" of
the begin-collection and end-collection value.
b) add a hyphen suffix to each attribute name in a collection.
For example, the "media-size" attribute in "media-col" is
encoded as "media-size-" and the "x" attribute in "media-size"
which is inside "media" is encoded as "x-". Note the hyphen
must be a suffix so that the attribute name follows the rules
for a legal keyword, and the hyphen is chosen because no
attributes currently end with a hyphen. The empty name is used
for the end-collection value and all but the first begin-
collection value.
2) encode attributes within a collection as a 1setOf values where
each attribute whose name is M and whose values are V1 ... Vn are
encoded as a sequence of n+1 values M, V1, ... Vn. Subsequent
member attributes continue the value in the 1setOf values.
The following are examples of encodings. In the real encoding, each
"attribute" consists of
a) a one byte tag
b) a two byte name length whose value is "n"
c) "n" bytes of a name
d) a two bytes value length whose value is "v"
e) "v" bytes of a value
[Expires: September 9, 2000]
To make it easy to read, we show only items c (the name), a (the tag)
and e (the value), in that order.
There are 3 encoding examples for each solution:
i) media-col with media-color and media-size as member attributes,
and where media-size contains "x" and "y" as collection members.
ii) media-size-supported with two collection values.
iii) job-notify with notify-recipients and notify-events which is a
1setOf keyword with 3 values in this example
Solution 1a)
Name syntax-type value
"media-col" begin-collection ""
"media-col.media-color" keyword white
"media-col.media-size" begin-collection ""
"media-col.media-size.x" integer 850
"media-col.media-size.y" integer 1100
"media-col.media-size" end-collection ""
"media-col" end-collection ""
Name syntax-type value
"media-size-supported" begin-collection ""
"media-size-supported.x" integer 850
"media-size-supported.y" integer 1100
"media-size-supported" end-collection ""
"media-size-supported" begin-collection ""
"media-size-supported.x" integer 850
"media-size-supported.y" integer 1400
"media-size-supported" end-collection ""
Name syntax-type value
"job-notify" begin-collection ""
"job-notify.notify-recipients" url "mailto://bill@foo.com"
"job-notify.notify-events" keyword job-completed
"" keyword job-created
"" keyword job-state-changed
"job-notify" end-collection ""
Solution 1b)
Name syntax-type value
"media-col" begin-collection ""
"media-color-" keyword white
"media-size-" begin-collection ""
"x-" integer 850
"y-" integer 1100
[Expires: September 9, 2000]
"media-size-" end-collection ""
"" end-collection ""
Name syntax-type value
"media-size-supported" begin-collection ""
"x-" integer 850
"y-" integer 1100
"" end-collection ""
"" begin-collection ""
"x-" integer 850
"y-" integer 1400
"" end-collection ""
Name syntax-type value
"job-notify" begin-collection ""
"notify-recipients-" url "mailto://bill@foo.com"
"notify-events-" keyword "job-completed"
"" keyword "job-created"
"" keyword "job-state-changed"
"job-notify" end-collection ""
Solution 2)
Name syntax-type value
"media-col" begin-collection ""
"" attribute-name "media-color"
"" keyword white
"" attribute-name "media-size"
"" begin-collection ""
"" attribute-name "x"
"" integer 850
"" attribute-name "y"
"" integer 1100
"" end-collection ""
"" end-collection ""
Name syntax-type value
"media-size-supported" begin-collection ""
"" attribute-name "x"
"" integer 850
"" attribute-name "y"
"" integer 1100
"" end-collection ""
"" begin-collection ""
"" attribute-name "x"
"" integer 850
"" attribute-name "y"
"" integer 1400
"" end-collection ""
Name syntax-type value
[Expires: September 9, 2000]
"job-notify" begin-collection ""
"" attribute-name "notify-recipients"
"" url mailto://bill@foo.com"
"" attribute-name "notify-events"
"" keyword "job-completed"
"" keyword "job-created"
"" keyword "job-state-changed"
"" end-collection ""
Observations:
Solution 1a have identical properties to solution 1b except that the
rules for encoding the name are more complicated for 1a, and the name of
the attribute appears before each end-collection and end-collection in
1a but only before the first begin-collection in 1b.
If a collection aware client sends a collection to a collection unaware
Printer:
For solutions 1a and 1b) the Printer sees many attributes in place of
the collection and it returns in the Unsupported attribute group, all of
the attributes: the attribute outside the collection and each attribute
in the collection with it altered name. Thus the unsupported attributes
have names that the client didn't send and they may be in an order that
makes it hard to reconstruct the collection. In addition, because the
"end-collection" has the same name as the attribute for 1a, some
printers will reject the job because the attribute appears twice. Also,
1a does not work for a 1setOf collection because the name of the
attributes appear in front of each begin-collection and thus cannot be
distinguished from two occurrences of the same attribute.
For solution 2) the Printer sees the collection as a 1setOf values where
some values have unknown syntax types and other values have known syntax
types. When a collection-unaware printer discovers it doesn't
understand an attribute that is a collection, it sees the unknown
attribute as a 1setOf rather than a collection. It still returns the
attribute-name with the out-of-band value "unsupported" making it easier
for the client.
7.1 encoding of a collection (using solution 1a)
NOTE: If we pick another solution to the encoding, this section will
change.
Each collection MUST have a globally unique name. Each attribute in an
attribute group or a collection MUST have globally unique name.
[Expires: September 9, 2000]
Uniqueness is generated by prepending the collection name to the
attribute using a period, '.' as a separator.
For encoding attributes that have a 'collection' attribute syntax, the
attribute's name is REQUIRED to be the first part of each of the member
attribute name separated by a PERIOD (.) character. For example, if a
"media-col" (collection) Job Template attribute is added to IPP and
contains a member attribute "color, it MUST be encoded as a "media-
col.color". In another example, if the "job-sheets" (collection) Job
Template attribute is added to IPP and reuses the "color" member
attribute, the "color" attribute MUST be encoded as "job-sheets.color".
The "xxx.color" attribute has an identical attribute syntax and similar
semantics.
When encoding a collection attribute "xxx" that contains an attribute
"aaa". A simplified example of a collection specification is given in
section 6
1.The beginning of the collection is indicated with a value tag that
MUST be syntax type 'begincollection' (e.g. 0x34).
2.The length of the collection name (e.g. 0x03)
3.The collection name (e.g. "xxx")
4.A null collection value length (e.g. 0x00)
5.The attributes are encoded as with any other attribute. It is valid
to have a collection a member of a collection. The modifications
necessary for encoding member attributes of a collection are as
follows.
a) The name of the member attribute MUST be prepended with the
collection name and a period.
b) The length of the member attribute name MUST be adjusted
appropriately.
6.The end of the collection is indicated with a value tag that MUST be
syntax type 'endCollection' (e.g. 0x37).
7.The length of the collection name (e.g. 0x03)
8.The collection name (e.g. "xxx")
9.A null collection value length (e.g. 0x00)
[Expires: September 9, 2000]
7.2 Sample Encoding (using solution 1a)
NOTE: If we pick another solution to the encoding, this section will
change.
This section defines the encoding of a collection syntax type using
solution 1a. The collection specified in section 6 is used. The
encoding is of an implementation that does not support any optional
attributes. A collection is encoded by using two new tags:
Tag name Tag Meaning Tag name Tag Meaning
value value
beginCollection 0x34 Begin the named collection. beginCollection 0x34 Begin the named collection.
endCollection 0x37 End the named collection. endCollection 0x37 End the named collection.
A collection value is encoded as a sequence of attribute values A collection value is encoded as a sequence of attribute values
preceded by a beginCollection value and followed by an endCollection preceded by a beginCollection attribute and followed by an endCollection
value. The value field of a beginCollection and an endCollection both attribute. The name field of a beginCollection and an endCollection both
contain the name of the collection type, which is a string of ASCII contain the name of the collection type, i.e., the keyword name of the
characters. These values allow a receiver to optionally match an collection attribute, which is a string of ASCII characters. The value
endCollection value with a beginCollection. A 1setOf collection is field contains the prefix used for all subordinate member attributes.
encoded using the rules for 1setOf and collection. The name field for The following example is written in the style of the IPP/1.1 "Encoding
the endCollection must be empty. The following example is written in the and Transport" document [ipp-pro]. The following example is for a media
style of the IPP/1.1 "Encoding and Transport" document [ipp-pro]. The collection attribute. The media collection contains 2 member
following example is for a job-notify attribute containing a set of 2 attributes. One member is "color" that contains a keyword for the
collections. media's color. The second attribute is a collection that gives the
media's size. The size collection has two integer attributes "x" and
"y" that gives the media's size in inches
Octets Symbolic Protocol comments Octets Symbolic Protocol comments
Value field Value field
0x34 beginCollecti value-tag Beginning of the
0x34 beginCollecti value-tag Beginning of the collection
on
0x0009 name- Length of collection's name
length
media-col media-col Name Collection's name
0x0000 Value-
length
0x44 keyword type value-tag Member attribute type
0x000F name- Length of member attribute
length name
media-col.color media- Name Name of member attribute
col.color
0x0004 value-
length
blue blue Value
0x34 beginCollecti value-tag Beginning of the sub-
on collection on collection
0x000a name-length
job-notify job-notify Name
0x000f Value-length
job-notify-coll job-notify- Value Collection type
coll
0x45 uri type value-tag "notify-recipients"
attribute
0x0010 name-length
notify-recipient notify- Name
recipient
0x0013 value-length
ipp- Value
notify:port=700
0x44 keyword type value-tag "notify-event-groups"
attribute
0x000d name-length
notify-events Name
0x0d value-length
job-completed Value
0x44 keyword type value-tag 2nd "notify-event-
groups" attribute
0x0000 name-length 0 length means next
multiple value
0x0011 value-length
[Expires: August 22, 2000] [Expires: September 9, 2000]
Octets Symbolic Protocol comments Octets Symbolic Protocol comments
Value field Value field
job-state-changed job- Value
completion
0x37 endCollection value-tag
0x0000 name-length
0x000f value-length
job-notify-coll Value Matches value of
beginCollection
0x34 beginCollecti value-tag Separator between
on collection values
0x0000 name-length
0x000f value-length
job-notify-coll Value Matches value of
beginCollection
0x45 uri type value-tag "notify-recipients"
attribute
0x0010 name-length
notify-recipient Name
0x0014 value-length
mailto:smith@foo.c Value
om
0x44 keyword type value-tag "notify-event-groups"
attribute
0x000d name-length
notify-events Name
0x0d value-length
job-completed Value
0x37 endCollection value-tag End of last collection
0x0000 name-length
0x000f value-length
job-notify-coll Value Matches value of
beginCollection
10 Legacy issues 0x000E name- Length of sub-collection's
length name
media-col.size media- Name Sub-collection's name
col.size
0x0000 Value-
length
If a client recognizes collections in responses, it MUST include the 0x21 integer type value-tag Member attribute type
"collection-syntax-recognized" operation attribute with the value of 0x0010 name- Length of member attribute
'true' in each operation whether or not the request contains a length name
collection. media- media- Name Name of member attribute
col.size.x col.size.x
0x0004 value-
length
0x0006 Value
If a Printer recognizes collections in requests, it MUST support the 0x21 integer type value-tag Member attribute type
"collection-syntax-recognized" Printer Description attribute with the 0x0007 name- Length of member attribute
value of 'true'. length name
media- media- Name Name of member attribute
col.size.y col.size.y
0x0004 value-
length
0x0004 Value
A client that supports collections MUST NOT send collections in a 0x37 endCollection value-tag end of the sub-collection
request to a Printer that does not recognize collections. 0x0007 name- Length of sub-collection's
length name
media-col.size media- Name Sub-collection's name
col.size
0x0000 Value-
length
A Printer that supports collections MUST NOT return collections in a 0x37 endCollection value-tag end of the collection
response to a client that does not recognize collections. 0x0007 name- Length of collection's name
length
media-col media-col Name Sub-collection's name
0x0000 Value-
length
[Expires: August 22, 2000] 7.3 1setOf Collection encoding (using solution 1a)
Although a client or Printer that doesn't recognize collections will The encoding of a set of collections follows the standard method of
skip over the beginCollection and endCollection tags as unrecognized encoding multi-valued IPP attributes. The "beginCollection" attribute
syntax types, the client or Printer will mistakenly assume that the is coded normally. The first instance of the collection follows. The
member attributes are outside of the unrecognized collection. Thus it "endCollection" MUST appear only once in a collection and MUST follow
is important that clients and Printers that don't recognize collections the last member of the set of collection. The member collections of a
not receive them.
11 IANA Considerations [Expires: September 9, 2000]
set of collections are delineated by a specially encoded
"beginCollection" attribute. The type MUST be "beginCollection" (i.e.
0x34). The length of the name field MUST be 0x0000. The name field
MUST be omitted. The length of the value MUST be the length of the
collection's prefix. The value MUST be the prefix.
7.4 Sample 1setOf Collection encoding (using solution 1a)
NOTE: If we pick another solution to the encoding, this section will
change.
This section defines the encoding of a collection syntax type using
solution 1a. The collection specified in section 7 is used. The
difference is that the type of "media-col" is 1setOf collection instead
of collection. The encoding is of an implementation that does not
support any optional attributes.
Octets Symbolic Protocol comments
Value field
0x34 beginCollecti value-tag Beginning of the collection
on
0x0009 name- Length of collection's name
length
media-col media-col Name Collection's name
0x0000 Value-
length
0x44 keyword type value-tag Member attribute type
0x000F name- Length of member attribute
length name
media-col.color media- Name Name of member attribute
col.color
0x0004 value-
length
blue blue Value
0x34 beginCollecti value-tag Beginning of the sub-
on collection
0x000E name- Length of sub-collection's
length name
media-col.size media- Name Sub-collection's name
col.size
0x0000 Value-
length
0x21 integer type value-tag Member attribute type
0x00010 name- Length of member attribute
length name
[Expires: September 9, 2000]
Octets Symbolic Protocol comments
Value field
media- media- Name Name of member attribute
col.size.y col.size.y
0x0004 value-
length
0x0006 Value
0x21 integer type value-tag Member attribute type
0x00010 name- Length of member attribute
length name
media- media- Name Name of member attribute
col.size.x col.size.x
0x0004 value-
length
0x0004 Value
0x37 endCollection value-tag end of the sub-collection
0x000E name- Length of sub-collection's
length name
media-col.size media- Name Sub-collection's name
col.size
0x0000 Value-
length
Second collection in set
0x34 beginCollecti value-tag Beginning of the collection
on
0x0000 name- Indicates continuation of
length set
0x0000 Value-
length
0x44 keyword type value-tag Member attribute type
0x000F name- Length of member attribute
length name
media-col.color media- Name Name of member attribute
col.color
0x0003 value-
length
red red Value
0x34 beginCollecti value-tag Beginning of the sub-
on collection
0x000E name- Length of sub-collection's
length name
media-col.size media- Name Sub-collection's name
col.size
[Expires: September 9, 2000]
Octets Symbolic Protocol comments
Value field
0x0000 Value-
length
0x21 integer type value-tag Member attribute type
0x0010 name- Length of member attribute
length name
media- media- Name Name of member attribute
col.size.y col.size.y
0x0004 value-
length
0x0006 Value
0x21 integer type value-tag Member attribute type
0x0010 name- Length of member attribute
length name
media- media- Name Name of member attribute
col.size.x col.size.x
0x0004 value-
length
0x0004 Value
0x37 endCollection value-tag end of the sub-collection
0x000E name- Length of sub-collection's
length name
media-col.size media- Name Sub-collection's name
col.size
0x0000 Value-
length
0x37 endCollection value-tag end of the set of
collections
0x0009 name- Length of collection's name
length
media-col media-col Name collection's name
0x0000 Value- Length of collection's
length prefix
8 Legacy issues
IPP 1.x Printers and Clients will gracefully ignore collections and its
member attributes if it does not understand the collection. The
begCollection and endCollection elements each look like an attribute
with an attribute syntax that the recipient doesn't support and so
should ignore the entire attribute. The individual member attributes
will look like ordinary attributes, but since they each are encoded with
[Expires: September 9, 2000]
a unique name that can't be the same as a top level attribute, each of
the member attributes will also look like attributes that the recipient
doesn't support and so should ignore.
9 IANA Considerations
This attribute syntax will be registered with IANA after the WG approves This attribute syntax will be registered with IANA after the WG approves
its specification according to the procedures for extension of the its specification according to the procedures for extension of the
IPP/1.1 Model and Semantics [ipp-mod]. IPP/1.1 Model and Semantics [ipp-mod].
12 Internationalization Considerations ISSUE 04 - Since this is intended to be a standards track document, do
we also register the attribute syntax with IANA?
10 Internationalization Considerations
This attribute syntax by itself has no impact on internationalization. This attribute syntax by itself has no impact on internationalization.
However, the member attributes that are subsequently defined for use in However, the member attributes that are subsequently defined for use in
a collection may have internationalization considerations, as may any a collection may have internationalization considerations, as may any
attribute, according to [ipp-mod]. attribute, according to [ipp-mod].
13 Security Considerations 11 Security Considerations
This attribute syntax causes no more security concerns than any other This attribute syntax causes no more security concerns than any other
attribute syntax. It is only the attributes that are subsequently attribute syntax. It is only the attributes that are subsequently
defined to use this or any other attribute syntax that may have security defined to use this or any other attribute syntax that may have security
concerns, depending on the semantics of the attribute, according to concerns, depending on the semantics of the attribute, according to
[ipp-mod]. [ipp-mod].
14 References 12 References
[ipp-mod] [ipp-mod]
Isaacson, S., deBry, R., Hastings, T., Herriot, R., Powell, P., Isaacson, S., deBry, R., Hastings, T., Herriot, R., Powell, P.,
"Internet Printing Protocol/1.1: Model and Semantics" draft-ietf- "Internet Printing Protocol/1.1: Model and Semantics" draft-ietf-
ipp-model-v11-04.txt, June 23, 1999. ipp-model-v11-06.txt, March 1, 2000.
[ipp-ntfy] [ipp-ntfy]
Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M., Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M.,
Bergman, R. " Internet Printing Protocol/1.0 & 1.1: IPP Event Bergman, R. " Internet Printing Protocol/1.0 & 1.1: IPP Event
Notification Specification" draft-ietf-ipp-not-spec-02.txt, work in Notification Specification" draft-ietf-ipp-not-spec-02.txt, work in
progress, February 2, 2000. progress, February 2, 2000.
[ipp-pro] [ipp-pro]
Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing
Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11- Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11-
03.txt, June 23, 1999. 05.txt, March 1, 2000.
[RFC2565] [RFC2565]
Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
Protocol/1.0: Encoding and Transport", RFC 2565, April 1999. Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
[Expires: August 22, 2000] [Expires: September 9, 2000]
[RFC2566] [RFC2566]
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell,
"Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566,
April 1999. April 1999.
[RFC2567] [RFC2567]
Wright, D., "Design Goals for an Internet Printing Protocol", RFC Wright, D., "Design Goals for an Internet Printing Protocol", RFC
2567, April 1999. 2567, April 1999.
skipping to change at page 11, line 29 skipping to change at page 25, line 29
[RFC2569] [RFC2569]
Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between
LPD and IPP Protocols", RFC 2569, April 1999. LPD and IPP Protocols", RFC 2569, April 1999.
[RFC2616] [RFC2616]
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1",
RFC 2616, June 1999. RFC 2616, June 1999.
15 Author's Addresses 13 Author's Addresses
Roger deBry
Utah Valley State College
Orem, UT 84058
Phone: (801) 222-8000
EMail: debryro@uvsc.edu
Tom Hastings Tom Hastings
Xerox Corporation Xerox Corporation
737 Hawaii St. ESAE 231 737 Hawaii St. ESAE 231
El Segundo, CA 90245 El Segundo, CA 90245
Phone: 310-333-6413 Phone: 310-333-6413
Fax: 310-333-5514 Fax: 310-333-5514
e-mail: hastings@cp10.es.xerox.com e-mail: hastings@cp10.es.xerox.com
Robert Herriot Robert Herriot
Xerox Corp. Xerox Corp.
3400 Hill View Ave, Building 1 3400 Hill View Ave, Building 1
Palo Alto, CA 94304 Palo Alto, CA 94304
Phone: 650-813-7696 Phone: 650-813-7696
Fax: 650-813-6860 Fax: 650-813-6860
e-mail: robert.herriot@pahv.xerox.com e-mail: robert.herriot@pahv.xerox.com
Roger deBry Kirk Ocke
Utah Valley State College Xerox Corp.
Orem, UT 84058 800 Phillips Rd
M/S 139-05A
Phone: (801) 222-8000 Webster, NY 14580
EMail: debryro@uvsc.edu
[Expires: August 22, 2000]
16 APPENDIX A: Example of collection usage
This section describes one collection Job Template example.
16.1"job-notify" Operation attribute
The following example illustrates the definition of a collection
attribute for the "job-notify" operation attribute (see [ipp-ntfy]).
Each column of the table corresponds to information that is required for
member attributes. Only the semantics have been omitted.
Member name Member type Supported- Client Printer
values supplied/ support
default
notify- uri notify- MUST MUST
recipient recipient-
schemes-
supported
notify-events 1setOf type2 notify-events- notify-events- MUST
keyword supported default
subscriber- octetString(63) <any octet <empty MUST
user-data string> octetString>
notify- charset charset- attributes- MAY
attributes- supported charset in
charset operation
group
notify- naturalLanguage generated- attributes- MAY [Expires: September 9, 2000]
attributes- natural- natural- Phone: (716) 442-4832
natural- language- language in EMail: kirk.ocke@usa.xerox.com
language supported operation
group
Note: for the "client supplied/default" column, the default is specified Peter Zehler
if it is OPTIONAL for the client to supply the member attribute in a Xerox Corp.
request. 800 Phillips Rd
M/S 139-05A
Webster, NY 14580
Phone: (716) 265-8755
EMail: peter.zehler@usa.xerox.com
17 Appendix B: Full Copyright Statement 14 Appendix A: Full Copyright Statement
Copyright (C) The Internet Society (1998,1999). All Rights Reserved Copyright (C) The Internet Society (1998,1999,2000). All Rights Reserved
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice may not be modified in any way, such as by removing the copyright notice
[Expires: August 22, 2000]
or references to the Internet Society or other Internet organizations, or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into Standards process must be followed, or as required to translate it into
languages other than English. languages other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
[Expires: August 22, 2000] [Expires: September 9, 2000]
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/