Revision marks show the additions. I hope we can consider this document
at the IPP telecon, Wednesday, 1/14/98, 1-3 pm PDT.
The files are available at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-requirements.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-requirements.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-requirements.txt
Here is a copy of the .txt file:
Subj: Strawman Requirements for encoding IPP protocol using XML
Date: 01/13/98
Files: ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-requirements.pdf
.doc .txt
Version: 0.1
To those developing XML encoding schemes for IPP:
Here are the coding requirements that our current IPP Protocol document
meets. A proposal for encoding IPP using XML should meet these
requirements too.
The current IPP protocol encoding specification is available as an
Internet-Draft as:
<draft-ietf-ipp-protocol-04.txt>.
The 05 version has been forwarded to the Internet-Drafts DL and will be
out shortly. It is currently available at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-980109.pdf
The current IPP Model and Semantics specification is available as an
Internet-Draft as:
<draft-ietf-ipp-model-08.txt>
ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-971219.pdf
Several requirements have alternative requirements listed immediately
following, with an "a" appended. We need to decide which requirement
should be the one we want to have.
The term "recipient" is used to indicate both a client and an IPP
object, since an IPP object receives requests from a client and a
client received responses from an IPP object.
Strawman Requirements for encoding IPP protocol using XML
The encoding of IPP in XML shall meet the following requirements:
1.Do not need to change the IPP Model document at all, or only at
least trivially. It has all of the semantics that we want to
represent.
2.Be registered as a MIME media type, that can be transmitted with any
transport, such as SMTP, rather than being restricted to HTTP 1.1,
i.e., be registered with Intended usage: COMMON.
3.Be able to represent all of the IPP operations: Print-Job, Print-
URI, Validate-Job, Create-Job, Get-Printer-Attributes, Get-Jobs,
Send-Document, Cancel-Job, and Get-Job-Attributes. See section 4.2
to 4.4 of the Model document. Each operation has a defined request
format and a defined response format, consisting of groups of
attributes.
4.In addition, the Print-Job and Send-Document requests have appended
document data which must be easily separable by the recipient.
5.The appended document must be able to be any text or binary document
format, including an XML document itself.
6.Also the Send-Document request must be able to be sent with no
document (if this is a problem for XML, we could add a new
operation, say, Close-Job, to close a multi-document job without
sending a document).
1
7.It must be possible for any version of a recipient to detect that
request or response is a later or earlier version for all future
versions.
8.Need to be able to represent all of the attribute syntaxes (data
types) that are in Section 4.1 of the Model document: 'text',
'textWithLanguage', 'name', 'nameWithLanguage', 'keyword', 'enum',
'uri', 'uriScheme', 'charset', 'naturalLanguage', 'mimeMediaType',
'octetString', 'boolean', 'integer', 'rangeOfInteger', 'dateTime',
'resolution', and '1setOf X' (multi-valued attributes). A
'dictionary' value is reserved for the future.
8a. A different, more natural to XML, method for overriding the
natural language for .text. and .name. attributes than using the
.textWithLanguage. and .nameWithLanguage. attribute syntaxes would
be acceptable.
8b. A different, more natural to XML, method for grouping a bunch of
attributes as the value of an attribute would be acceptable to
having a 'dictionary' attribute syntax.
9.Keywords are used to identify attributes and attribute values and
are specified in lower case US-ASCII and U.S. English and allow
hyphen (-), dot (.) and underscore (_).
9a. Using keywords to identify attribute syntaxes would be
desirable, though not currently done in our current IPP protocol.
10.Implementers must be able to add private keywords using private
keyword syntax for which clash with other implementers. private
keywords is not possible. Implication: a recipient must be able
ignore any attributes (and values) not recognized and/or supported
and continue parsing a request or response.
11.The PWG must be able to add additional attribute syntaxes following
a registration procedure that includes PWG review. Implication: a
recipient must be able ignore any attributes (and values) not
recognized and/or supported and continue parsing a request or
response.
12.Implementers must be able to include private attribute syntaxes in
conforming interchange. Implication: a recipient must be able
ignore any attribute syntaxes not supported and continue parsing a
request or response.
10a. It would be desirable if clashes with other implement private
attribute syntaxes could be guaranteed to be avoided - something
that our current IPP encoding does not solve, since attribute
syntaxes are encoded as integers without a registration scheme.
Using keywords for attribute syntaxes would be a way to achieve such
name clash avoidance.
13.Implementers must be able to add private enum values.
14.Attributes must be identified by keywords in US-ASCII and US-
English.
15.Some attribute syntaxes must be able to be defined to be a value
that contains several distinct specific data types in a specific
order, like a C struct. Currently, each such value must be present,
there is no need for values to be optional in such a structure.
2
16.Attributes must be able to be multi-valued, i.e., to have multipl
instances of the value.
17.The syntax specification must be able to indicate which attribute
are permitted to be multi-values, and which must be single valued.
18.Any attribute must be able to have "out-of-band" values, i.e.,
values that can be used with any attribute and attribute syntax.
Currently, we have the following "out-of-band" values:
'unsupported', 'unknown', 'no-value', with 'default' reserved for
the future.
19.Some attributes must be able to have more than one attribute syntax
defined for them, such as .keyword. and .name. (or .text. and
.textWithLanguage. if that mechanism is used for overriding natural
language on an attribute value by attribute value basis).
20.An instance of a multi-valued attribute must be able to employ any
of the attribute syntaxes defined for it. For example be able to
mix .keyword. and .name. values.
21.Each value of an attribute needs to identify which attribute syntax
it is using.
22.The .text. and .name. attribute syntaxes must be able to represent
any ISO 10646 character, probably using utf-8 encoding.
23.The .text. and .name. attribute values must be representable in
other charsets than utf-8. Possibly, some simple coding
transformation may be required by the client for some charsets.
There is no need for this to be done on an attribute by attribute
basis. Only a single request or a single response needs to be in a
charset specified in the interchange.
24.It must be possible to group attributes in an interchange into
several groups.
For requests: Operation attributes and Job Template attributes.
For responses: Operation attributes, Job Attributes, Printer
Attributes, Job Description Attributes, Printer Descriptions
Attribute, Unsupported Attributes.
25.Attribute groups must be identified as to which group.
26.The syntax definition should restrict the order of occurrence of
attribute groups.
27.The recipient should be able to ignore entire attribute groups that
are not recognized and/or supported.
28.No syntactic distinction is needed between multi-valued attributes
that are ordered, and ones that are not. The semantics specify
which attributes are ordered and which are not (most are not).
29.Similarly, no syntactic distinction need be made between attribute
groups that require certain attributes to be first and ones that do
not. The semantics specify which attributes must come first in
which groups. Most attribute can occur anywhere in the groups in
which they are permitted.
3