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