Subject: Re: IPP> ADM> IPP 1.0 Issues List?

From: "Scott Isaacson" <[email-masked]>
Date: Thu, 28 May 1998 09:33:31 -0600

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?  Form?

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.

---

From: Jay Martin <[email-masked]>
Date: Thu, 28 May 1998 11:47:43 -0400

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:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Tom Hastings <[email-masked]>
Date: Fri, 29 May 1998 07:49:10 PDT

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

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)

     http://www.ietf.org/internet-drafts/draft-ietf-ipp-req-01.txt

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

     http://www.ietf.org/internet-drafts/draft-ietf-ipp-model-09.txt

Mapping between LPD and IPP Protocols (52648 bytes)

     http://www.ietf.org/internet-drafts/draft-ietf-ipp-map-03.txt

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

     http://www.ietf.org/internet-drafts/draft-ietf-ipp-protocol-05.txt

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

Printing Protocol (23639 bytes)

     http://www.ietf.org/internet-drafts/draft-ietf-ipp-rat-02.txt

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 
be

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

     4 - Not registered. Only applicable to local administrative

     domains.

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 
change

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

2

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

     attributes

There was a clarification about the order of operation attributes in 
IPP

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

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

'uri'.

3.1.6Clarify that the simplest PrintJob must include the target

     operation attributes

An inconsistency was identified within the Operations attribute group 
of

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

attribute(s).

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

added.

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

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

3

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 
require

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

required.

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 
might

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 
request

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 
just

references two other ISO standards.  We resolved clarify the reference

4

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 
editor

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

</bigger>

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

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

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