IPP Mail Archive: Re: IPP> ADM> IPP 1.0 Issues List? [extracted from 5/20

IPP Mail Archive: Re: IPP> ADM> IPP 1.0 Issues List? [extracted from 5/20

Re: IPP> ADM> IPP 1.0 Issues List? [extracted from 5/20

Tom Hastings (hastings@cp10.es.xerox.com)
Fri, 29 May 1998 07:49:10 PDT

Here are the extracted issue resolutions from the IPP .txt minutes of

5/20 meeting:

<bigger>3 Bug fixes in current IPP/1.0 documentation

The current IPP/1.0 documentation is defined by a suite of Internet-

Drafts as submitted to the IESG:

Requirements for an Internet Printing Protocol (104985 bytes)


Internet Printing Protocol/1.0: Model and Semantics (435327 bytes)


Mapping between LPD and IPP Protocols (52648 bytes)


Internet Printing Protocol/1.0: Protocol Specification (75544 bytes)


Rationale for the Structure of the Model and Protocol for the Internet

Printing Protocol (23639 bytes)


3.1 Model Document changes

ACTION ITEM (Scott): Make these changes while working with the RFC

editor to turn the Model specification into an RFC:

3.1.1Clarify that the success status code doesn't mean job has printed

A sentence will be added to clarify that the .Success. status code does

not mean the print operation was entirely successful. It means that the

request has been received, is valid and a job object was created.

3.1.2No further clarifications of the 'stopped' Printer state needed

There was a question about whether or not the .Stopped. Printer State

needs clarification. New wording, added since Portland, was agreed to

sufficient and no further changes are anticipated.

3.1.3Remove type4 keywords and use type3 keywords (and names) instead

There was a question about the purpose and value of Type-4 keywords.

Keyword types were explained, as follows:

1 - Must republish the standard to extend. Example - Job States.

2 - Extended or enhance with PWG approval.

3 - Extended or enhanced via registration (IANA) w/o PWG

4 - Not registered. Only applicable to local administrative


Example of attributes using type 4 keywords: "media", "job-sheets", and

"job-hold-until". They all have the syntax: (type4 keyword |

name(MAX)). Because we also allow 'name' syntax, we decided it is best

to eliminate the Type-4 enumeration from the specification and to

these three attributes to: (type3 keyword | name(MAX)).


PWG Internet Printing Project - Minutes May 20-21, 1998

may supply localized names within their own domains. So a system

manager can only defined names, not keywords. It seems too difficult

for a client to have to discover new keywords have been added by the

system administrator and then obtain their localization (somehow) in

different languages for display to the end-user. Instead, the 'name'

attribute syntax will be clarified to indicate that the "name" exists

for administrator to add values that are not supported by the

implementation. See Bob Herriot's email of March 18 and 19 for a

complete discussion.

3.1.4Order of "charset", "natural-language", and Target operation


There was a clarification about the order of operation attributes in

requests and responses. The "charset" attribute must come first

by the "natural-language" attribute. For requests, the target

attribute(s): "printer-uri", "job-uri", or "printer-uri followed by

job-id" must come next. This ordering facilitates processing of the

remaining operation attributes by the server.

3.1.5Clarify that the syntax of "printer-uri" and "job-uri" is 'uri'

Clarify that the attribute syntax of "printer-uri" and "job-uri" is


3.1.6Clarify that the simplest PrintJob must include the target

operation attributes

An inconsistency was identified within the Operations attribute group

the PrintJob section in that the simplest operation is defined as the

set of document content, "charset" and "natural-language" operation

attributes. This section will be revised to include the target


3.1.7Clarify the notation for Mandatory and Optional in Section 15.3.

The mandatory table in Section 15.3 is ambiguous. Tom proposed a

clarification that, when talking about mandatory and optional, here, we

are not defining the terms mandatory and optional, rather we are

defining which things must be implemented and which things may be

supplied. Tom.s clarifying text (as posted in previous e-mail) will be


3.1.8Keep 'uri' syntax and attribute names; don't change to 'url'

In Portland, we agreed to continue to use URI syntax name but note that

these are really URL.s. Now, there is some question whether this is

appropriate in light of some new RFC related to URI.s. ACTION ITEM (Bob

Herriott): research and report.

3.1.9Redefine 'client-error-uri-too-long' to be 'client-error-too-long'

There were questions about two, potentially redundant, client status

error codes

1. client-error-request-uri-too-long


PWG Internet Printing Project - Minutes May 20-21, 1998

2. client-error-bad-request

Do we need both? Which one do you use if URI is too long? Do they apply

to all URI.s or just the "document-uri" attribute? Should .too long.

apply to ANY attribute that is string-like? We decided that an error

with semantics .Too Long. should be defined for any data type that is a

variable number of octets with a maximum length.

3.1.10 ISSUE: Some text and name attributes are constrained to be

shorter than MAX

We further addressed the problem of string overrun in constrained

resource implementations by proposing additional syntax types such as

'shortName', and 'shortText' which would be 63 and 127 bytes,

respectively, for example). The goal is to allow the length syntax

checking to be solely based on attribute syntax code, and not depend on

which attribute is being supplied. To accomplish this goal will

the addition of at least one new attribute syntax.

ACTION ITEM (Scott or Bob): Need a detailed proposal.

3.1.11 Reaffirmed that target attributes must be supplied in the

request redundantly

We agreed that target attributes should be redundantly carried inside

the IPP operation as well as externally in the HTTP request header.

This redundancy is necessary to keep the IPP MIME media type transport-

independent. There was debate over the architectural soundness of this

proposal, as it would prevent simple re-routing of the job to a new

target based on information from the request header. Instead, to re-

route, the embedded target must be learned from examination of the IPP

stream. It also complicates test. Following discussion, there was

strong opinion not to change anything so the decision to adopt this

change (which had already been made - target attributes inside the

operation) stands as is and test tools must deal with the situation as


3.1.12 Clarified that the target URI are absolute form

Per above, suppose we have printer URI inside the operation, but also

have it in the HTTP request header mapping. There is the issue of

Absolute vs. Relative addressing of the target. Internal to the IPP

operation, only Absolute URL.s apply. But, in the HTTP header, it

be Relative. We reiterated that the internal URI is mandatory but the

server does not need to check it for routing. In fact, the HTTP

header URI, if present, takes precedence. The internal URI should

reference the same URI as the one in the HTTP header (should not be

garbage). The external URI may be Relative.

3.1.13 Clarify that the reference to RFC 1766 includes the ISO

standards that it references

Inside the model document, we talk about natural language syntax from

RFC1766: 'en', 'fr', etc. But RFC1766 doesn.t give these values it

references two other ISO standards. We resolved clarify the reference


PWG Internet Printing Project - Minutes May 20-21, 1998

to RFC1766 as pertaining to syntax, and add a reference to the proper

references for the actual values:

[ISO 639]

ISO 639:1988 (E/F) - Code for the representation of names of

languages - The International Organization for

Standardization, 1st edition, 1988 17 pages Prepared by

ISO/TC 37 - Terminology (principles and coordination).

[ISO 3166]

ISO 3166:1988 (E/F) - Codes for the representation of names

of countries - The International Organization for

Standardization, 3rd edition, 1988-08-15.

3.2 Protocol Document changes

ACTION ITEM (Bob): Make these changes while working with the RFC

to turn the Model specification into an RFC:

3.2.1Change name from "Protocol" to "Encoding and Transport"

Name should be changed from "Protocol" to "Encoding and Transport".

3.2.2Add "printer-uri" operation attribute to examples

Add "printer-uri" operation attribute to examples to agree with the

Model document.

3.2.3Change all attributes to lower case in examples

Change some upper case to lower case to agree with the Model document.

3.2.4Change the reserved 'dictionary' attribute syntax to 'collection'

Change the name of the reserved 34 attribute syntax code from

'dictionary' to 'collection'.


At 08:47 05/28/1998 PDT, Jay Martin wrote:

>Given the importance of reconciling outstanding issues,

>as well as maintaining an easy-to-follow thread on the

>IPP Hypermail archives, would it be in our best interest

>to extract the issue resolutions from the meeting notes

>and post them as a follow-up to this thread?


>If this effort is too much for the IPP worker bees to

>assume, I'll be more than happy to do the extract/post

>myself, if you'd prefer.


> ...jay



>-- JK Martin | Email: jkm@underscore.com --

>-- Underscore, Inc. | Voice: (603) 889-7000 --

>-- 41C Sagamore Park Road | Fax: (603) 889-2699 --

>-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --




>Scott Isaacson wrote:


>> I wouldn't mind an issues list, but the ones that you mentioned were
all raised and discussed at the last meeting. See comments below.


>> >1. "printer-uri" or "job-uri" mandatory and required op att?


>> Discussed and resolved at the 5/20-21 meeting. See new text to be
published by 5/29.. Meeting notes

>> due out soon.


>> >2. Mixed case allowed in 'naturalLanguage' and 'charset' values?


>> What is the issue? The model document syntax rules for charset and
naturalLanguage state that IPP does not allow mixed case. 4.1.9
'charset' currently says:


>> "Though RFC 2046 requires that the values be case-insensitive
US-ASCII, IPP requires all lower case to simplify comparing by IPP
clients and Printer objects."


>> 4.1.10 'naturalLanguage' currently says:


>> "Though RFC 1766 requires that the values be case-insensitive
US-ASCII, IPP requires all lower case to simplify comparing by IPP
clients and Printer objects."


>> >3. 'client-error-request-uri-too-long' vs.

>> >'client-error-request-value-too-long' ? Types applied to?


>> Discussed and resolved at the 5/20-21 meeting. See new text to be
published by 5/29 Meeting notes

>> due out soon.


>> >4. "attributes-charset" and "attributes-natural-language" must
always be

>> >positioned up front?


>> Discussed and resolved at the 5/20-21 meeting. See new text to be
published by 5/29 Meeting notes

>> due out soon.