An Analysis of XML as the IPP protocol

An XML Schema which Defines IPP

Robert Herriot, Sun Microsystems

robert.herriot@eng.sun.com

Introduction

This document uses an XML schema to define the XML encoding of IPP as defined in a previous document (Ipp-xml-980210.doc). The schema is defined in the "XML Data" document, which is available from W3C.

The schema defines the following characteristics of IPP

The structure with regard to the attribute groups
Which attribute groups are mandatory or optional in each operation
Which operation attributes are mandatory, optional for the client and optional to implement
Which job and printer attributes are mandatory, optional for the sender, and optional to implement
Which attributes must be implemented as a group.
What types and values are allowed for each attribute
Which types must be explicitly typed for an attribute.
The order or lack of order of various components.

IMPORTANT NOTE: This document should be treated as a preliminary draft. I have tried to follow the XML Data document as much as possible, and where I have made extensions, I have tried to be as consistent as possible. This document is intended to stimulate discussion in the IPP community and the XML Data community. For the former, it shows how IPP can be specified. For the latter, it is an extended example which shows the strengths and need for extensions to define a real protocol.

Table of Contents

Introduction *

Table of Contents *

Schema for IPP Request *

Schema for IPP Response *

Schema for IPP Job Template Attributes *

Schema for IPP Job Description Attributes *

Schema for IPP Printer Description Attributes *

Schema for IPP Data Types *

Schema for IPP Supertypes *

Schema for IPP Contexts *

Schema for IPP Request

The schema that defines all IPP requests is below. The comments contain references to Section 15.3 in the model document where details of the protocol are spelled out. This schema could replace section 15.3 entirely or almost entirely.

I have extended the schema to include a context element and a context XML attribute. This extension allows me to make IPP attributes be defined only for certain operations.

To make the text easier to read, all comments are in blue, though they conform to XML syntax rules. There are numerous comment to explain an attribute or element the first time that it is used.

<s:schema id= "request" >

<!-- I have not used the attribute 'content="CLOSED"'. Thus undefined child

elements are also allowed anyplace as siblings of the defined children. This is

less restrictive than section 15.3.4.2. The XML rule is simpler to specify -->

<description>The root of the operation.</description>

<!-- the operation and job elements must appear in the order shown below according to the

rules of XML Data -->

<element type="#operation" occurs="REQUIRED"

error = "client-error-bad-request" />

<element type="#job" occurs="REQUIRED" context = "printOrSend"

error = "client-error-bad-request" />

<!-- section 15.3.4.1. If context (defined in a later section) is "printOrSend", then "job" is

REQUIRED-->

<attribute id="operation" occurs = "REQUIRED" dt = "enum" min = "2" max = "0xB"

error = "server-error-operation-not-supported" /> <!-- section 15.3.2 "operation attribute is

REQUIRED. The attribute "dt" specifies the "data type", and the attributes "min" and "max"

restrict the range of allowed values. I have added an "error" attribute to specify the error if

the REQUIRED attribute is not present or the value is not allowed. Note: there could be a

separate attribute for an error when the value is disallowed if the message is different. -->

<attribute id="version" occurs = "REQUIRED" dt = "string" values = "1.0"

error = "server-error-version-not-supported" />

<attribute id="xml:lang" dt="language" occurs = "REQUIRED"

error = "client-error-bad-request" /> <!-- section 15.3.5, "values" is not specified because any

value whose data type is "language" is allowed. -->

<attribute id="request-id" dt="int" occurs = "REQUIRED"

error = "client-error-bad-request" />

</elementType >

<description>Contains operation attributes.</description>

<!-- the "AND" means that all group children must occur, but in any order, with no "groupOrder

specified, all group children must occur and they must be in the specified order. The "occurs"

default is "REQUIRED" so I left it out here. It is the children that determine what it really

required. -->

<element type="#printer-uri" dt = "uri" occurs="REQUIRED" context = "PrinterOp"

error = "client-error-bad-request" />

<element type="#printer-uri" dt="uri" occurs="REQUIRED"

error ="client-error-bad-request" />

<element type="#job-id" dt ="int" occurs="REQUIRED"

error="client-error-bad-request" />

</group >

<element type="#requesting-user-name" occurs="OPTIONAL" dt = "name"

default = "anonymous" />

<!-- OPTIONAL means that the processor understands the element but it may be absent in a

request. The "default" attributes specifies the value when the element is absent -->

<element type = "#last-document" dt = "boolean" occurs="REQUIRED" context = "Send"

error = "client-error-bad-request" />

<default> <!-- default is value of document-name or document-uri. This an alternate to

XML attribute "default" which is for non structured values. -->

<!-- This element represents the value of "document-name"

There are unresolved issues about specifying the object

Containing "document-name" -->

</group>

</default>

</element>

<!-- "#LINKED" means that the processor implements this element if it also implements

the like named element, "job-k-octets" in this case. If the processor does not

implement the linked element, the processor treats this element as undefined. There

are unresolved issues pertaining to what object the name is in. -->

</group >

<element type="#compression" occurs="OPTIONAL" implement = "LINKED"

context = "PrintOrSend" dt = "compressionKeyword" default = "none" />

<element type="#message" occurs="OPTIONAL" context = "CancelJob"

implement = "OPTIONAL" dt = "text" />

<element type="#document-natural-language" occurs="OPTIONAL"

implement="OPTIONAL " dt = "language" />

<!-- This element does not depend on a definition, so 'implement="OPTIONAL" is

enough-->

</group >

<element type="#document-format" occurs="OPTIONAL"

context = " PrintWDocOrGetPrinterAttr " dt = "mimeMediaType" />

</element>

<element type="#document-uri" occurs="REQUIRED" context = "Doc-URI"

error = "client-error-bad-request" dt = "uri" />

<element type = "item" occurs="ONEORMORE" dt = "keyword"

valuesOfSuperType = "job" />

<!-- "valueOfSuperType" means that the values allowed are the names of each

element which is a member of the superType. There are issues about

whether names, such as "all" are handled by my "nickName" attribute-->

</datatype>

</element>

<element type = "item" occurs="ONEORMORE" dt = "keyword"

valuesOfSuperType = "job" />

</datatype>

</element>

<element type = "item" occurs="ONEORMORE" dt = "keyword"

valuesOfSuperType = "printer" />

</datatype>

</element>

<element type="#limit" occurs="OPTIONAL" context = "Get-Jobs" dt = "int"

default = "#MAXINT" />

<element type="#which-jobs" occurs="OPTIONAL" context = "Get-Jobs" dt= "keyword"

values = "completed not-completed" default = "not-completed" />

<element type="#my-jobs" occurs="OPTIONAL" context = "Get-Jobs" dt = "boolean"

default = "0" />

</group>

</elementType >

<description>Contains job attributes.</description>

<!-- This defines the default of this element in the context of a job attribute group

The value is of some other attribute -->

</element>

<!-- This defines the allowed value of this element in the context of a job attribute group

The value is of some other attribute. This overrides the values specified in the

definition which specifies all values allowed by the standard. -->

</element>

</element>

</element>

</element>

</values>

</element>

</ condition >

</element>

</group>

</element>

</element>

<element type="#orientation-requested" occurs="OPTIONAL" implement = "LINKED"

</element>

</element>

</element>

</element>

</group>

</elementType >

</schema >

Schema for IPP Response

This section is still being worked on. References to section 15.3 are not complete.

<s:schema id= "response" >

<!-- I have not used the attribute 'content="CLOSED"'. Thus undefined child

elements are also allowed anyplace as siblings of the defined children. This is

less restrictive than section 15.3.4.2. The XML rule is simpler to specify -->

<description>The root of the operation.</description>

<!-- the operation and job elements must appear in the order shown below according to the

rules of XML Data -->

<attribute id="operation" occurs = "REQUIRED" dt = "enum" min = "2" max = "0xB"

error = "server-error-operation-not-supported" /> <!-- I have added an operation attribute in the

response so a response can be verified without reference to its request . If this is not added

then I need a mechanism for a "context" in a reponse to look at an attribute in the request -->

<attribute id="version" occurs = "REQUIRED" dt = "string" values = "1.0"

error = "server-error-version-not-supported" />

<attribute id="xml:lang" occurs = "REQUIRED" dt="language"

error = "client-error-bad-request" /> <!-- section 15.3.5, "values" is not specified because any

value of whose data type is "language" is allowed. -->

<attribute id="request-id" occurs = "REQUIRED" dt="int"

error = "client-error-bad-request" />

</elementType >

<description>Contains operation attributes.</description>

</group>

</elementType >

<description>Contains unsupported attributes.</description>

<element occurs = "ONEORMORE"/> <!-- This allows anything. With more work we could

probably specify what the levels of syntax really mean -->

</elementType >

<description>Contains operation attributes.</description>

</group>

</elementType >

<description>Contains operation attributes.</description>

<!-- the supertype stands for any element that is a member of "job". I think this is not exactly what

XML Data means by super type.This needs work -->

</elementType >

<description>Contains operation attributes.</description>

</elementType >

<description>Contains operation attributes.</description>

</elementType >

</schema >

Schema for IPP Job Template Attributes

This section defines the job template attributes.

<!-- The supertype specifies the membership in a supertype. This is redundant with the

supertype definitions elsewhere. -->

</group >

<!-- "altdts" defines alternate datatype, which require an explicit "dt" attribute

"keywordHoldUntil" is specified in the data type section. The type implies the

allowed values. -->

<elementType id="#job-hold-until-default " supertype = "printerT" dt = "keywordHoldUntil"

altdts = "name" />

</elementType>

</group >

<elementType id="#job-sheets-default" supertype = "printerT" dt = "keywordJobSheets"

altdts = "name" />

</elementType>

</group >

<elementType id="#multiple-document-handling-default" supertype = "printerT"

dt = "keywordMultiDoc" />

</elementType>

</group >

</group >

</group >

</group >

</elementType>

</group >

</elementType>

</group >

</elementType>

</group >

</elementType>

</group >

</elementType>

</group >

</elementType>

</group >

</schema >

Schema for IPP Job Description Attributes

TBD

Schema for IPP Printer Description Attributes

TBD

Schema for IPP Data Types

This schema defines the data types for IPP. "dt" is the XML attribute used to name a set of values. There are some primitive "dt"s, namely "int", "string", "uri", "dateTime" and "boolean". "DateTime" uses ISO 8601 format. The others are built from them. The XML attribute "value" specifies the allowed values if it is a subset of that specified by "dt". The XML attributes "min" and "max" is another way of specifying the values by giving the lower and upper bounds of the range.

<datatype id = "urischeme" dt = "string" maxOctets = "63" codeset = "US-ASCII"

values = "http https ftp mailto file" content = "OPEN" />

</datatype>

</datatype>

<datatype id = "keywordHoldUntil" dt = "keyword"

values = "no-hold day-time evening night weekend second-shift third-shift" />

<datatype id = "keywordMultiDoc" dt = "keyword" values = "single-document

separate-documents-uncollated-copies separate-documents-collated-copies" />

</datatype>

</datatype>

<datatype id = "keywordSides" dt = "keyword" values = "one-sided two-sided-long-edge

two-sided-short-edge " />

<datatype id = "keywordMedia" dt = "keyword" values = "default iso-a4-white na-letter-white top middle

bottom envelope manual iso-a4 na-letter" />

</schema >

Schema for IPP Supertypes

This section shows the hierarchy of names used to refer to attributes. The "nickName" XML attribute defines the name that is used elsewhere to reference to collection of elements.

<!-- The supertype "job" is defined. It is referred to by "all" in a job context and contains two

supertypes "jobT" and "jobD". -->

</superElementType >

</superElementType >

</superElementType >

</superElementType >

</superElementType >

</superElementType >

</schema >

Schema for IPP Contexts

This section defines various contexts, which are referenced in the request and response schemas. All of the contexts here specify a set of operations. The request and response schemas use this to specify the operations in which a particular element is allowed.

<s:schema >

<!-- A series of contexts are defined. They are referenced in element and XML attribute definitions,

and control whether an element or XML attribute is present for a particular operation.-->

</group >

</element>

</context>

</group >

</element>

</context>

</group >

</element>

</context>

</group >

</element>

</context>

</group >

</element>

</context>

</group >

</element>

</context>

</group >

</element>

</context>

</group >

</element>

</context>

</group >

</element>

</context>

</element>

</context>

</element>

</context>

</element>

</context>

</element>

</context>

</schema >