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: . 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: 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