Subject: IPP> PRO - Updated requirements for XML encoding of IPP

From: Tom Hastings <[email-masked]>
Date: Tue, 13 Jan 1998 09:26:41 PST

I've updated the Strawman Requirements for encoding IPP protocol using XML.

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

---

From: Carl Kugler <[email-masked]>
Date: Tue, 13 Jan 1998 15:17:47 -0500

> format, including an XML document itself.

I think this is important (and I don't see how large binary objects can be sent
within XML).

>  i.e., be registered with Intended usage: COMMON.

I'd like to add:  "All IPP operations shall be mappable to the HTTP/1.1 POST
method."

-Carl Kugler