Please read the following draft minutes taken by Steve Zilles during the
meeting. If any of the meeting participants have copmments or if any of the
non-attendents need further clarifications, give us those back on the DL ASAP.
The only area that still seems somewhat uncertain is whether the IESG will
like our security solutions, but we signalled in the meeting that we now
want the IESG to hold the formal review and to give us their explicit
feedback if they are not yet happy.
Regards,
Carl-Uno
--
Minutes IETF IPP WG Meeting, 97/12/10, Washington DC
1-3PM, Executive Meeting Room
Carl-Uno began the meeting with an overview of the documents and the agenda
for the meeting:
Review suggested resolution of existing issues on
Model and Semantics document, Scott Isaacson
Protocol Specification document, Bob Herriot
In the recording below, issues and their suggested resolution are recorded
as presented (sometimes with some expansion for clarity). In most cases
there was no discussion and the proposed solution was accepted as
presented. If there was a discussion, this is recorded after the presented
solution and if a different decision was made, this is recorded after the
discussion as a decision.
Model Document Issues, Scott Isaacson
1. Major/Minor Versioning Rules
Mandate common encoding across all versions
All elements added in a new minor version can be ignored
New major version indicates new support requirements
2. Allow empty attribute groups
Be conservative in what is sent; send an empty group
Be liberal in what is received; allow missing group on reception
3. ALL operations MAY return "Unsupported Attributes"
4. Define protocol value-size upper bounds for
URIs, charsets, natural languages, identifiers, ...
5. MUST-implement requirements for text and name strings; each string has
a maximum length specification:
some 63 octets, others 127 or 1023 octets
Clarified validation checks for operation processing
Non-secure implementation
client supplies "requesting-user-name"
If client does not supply a name, the printer will generate one (which need
not be unique)
Discussion:
Is an authenticated mode required of all Printers
Keith Moore would like to have this be true; without it the protocol will
not be interoperable; that is, two implementations of the spec may not be
able to find a common (authenticated) communication path
Keith asserts that the current rules require this, because use of an
Internet accessible printer will require authentication; Keith believes
that submitting it as documented will cause kick back from the IESG.
But, for interoperability, it is not the case that both client and server
must do all the mechanisms as long on one or the other must do all; that
means that requiring all clients to do the secure solution is enough to
meet Keith's understanding of the rules
Jim Gettys: HTTP has an issue raised by Lotus to multiple servers, serving
a single site; It appears that Digest Authentication (with a few tweaks
based on an idea of Paul Leach) may meet this need.(and that Microsoft and
Netscape may be likely to implement Digest) Details on this discussion will
play-out on the HTTP mailing list over the next few weeks.
Keith Moore: Whether Digest Authentication is enough is not an issue of
whether it is secure enough, but whether this solution is sufficiently
scalable (Jim G asserts that Paul Leach's solution may solve the
scalability issue)
Keith points out that Diffie-Hillman is a (now) unencumbered mechanism for
key exchange and should be relatively easy to implement.
It is noted that there are two different classes of interoperation over the
Internet: (1) remote access to a private resource (such as the printer on
my desk) versus (2) providing a service to all comers (such as a Kinko's
service) over the Internet. Scalability is not an issue in the first case.
It was suggested that we identify the basic mode as "authenticated" mode
(because Digest Authentication is already mandated for all HTTP/1.1
clients) and the full TLS based mode as secure mode.
Decision:
Digest authentication is already mandated for all HTTP/1.1 clients
IPP will mandate TLS for all clients
8. Removed "copies-collated" attribute
9. Identified sources for all text and name valued attributes:
end user
device vendor,
operator
administrator
allow any natural language for non-generated strings
name change to "generated-natural-languages-supported"
10. Keep "charset-supported"
11. Clarified semantics of "page-range" attribute
12. Support for Media attributes
If supporting "media-default", then MANDATORY
If supporting "media-supported", then MANDATORY
If supporting "media-ready", then OPTIONAL
13. Added missing status codes
"server-error-not-accepting-jobs"
"server-error-version-not-supported"
14. Asserted that IPP is already aligned with
<draft-iesg-iana-considerations-01.txt>
15. Made "application/ipp" a "common usage" media type
added "request ID" to allow matching of responses to corresponding request
for protocols other than HTTP (e.g. SMTP)
included all parameters, including the target object URI, within the
application/ipp body
16. Security
Allow for "non-secure", really "authenticated" servers
If Privacy and/or Mutual Authentication is implemented, then it Shall be TLS
For HTTP/1.1, mandate and allow what HTTP/1.1 mandates and allows
Decision:
rename "non-secure" to "authenticated"
rename "secure" to "private and authenticated" (or something similar
Discussion:
WEBDAV has been asked to not allow basic authentication.
17. Provide input to the SVRLOC Printer Scheme I-D
18. Register all the SNMP printer languages as a (MIME) media types with
cross references to the SNMP enums
19. Register "application/ipp" as a media type
Keith said the preferred method for handling the MIME type registration is
to put the registration text (as per RFC2048) into the standards track RFC
that uses/defines it. IANA should then automatically add it to the registry
within a few days of the publication of the RFC.
New Issues:
20. Should we register new ports for IPP use
Keith Moore: a reason for a separate port number is to allow firewalls to
be configured to allow or block the printing port.
But, Keith observes that firewall usage is typically to block all access
except to particular servers and if HTTP is not allowed, then it is likely
that printing would also not be allowed so this is not a big issue. Hence,
Keith is neutral on registering a port for IPP
IESG has made TLS remove creation of new ports for other protocols than
HTTP. Ones that are already deployed were kept, but no new ones. Therefore,
we should not have a separate new port for IPP over TLS
Other than the port discussion, no new issues were raise
Protocol Document Issues since August 1997, Bob Herriot
1. Attribute Group Tags
Sender (of request or response) SHOULD send attribute group tag with no
following attributes with the exception of the unsupported-attributes-tag
which SHOULD be omitted
Recipient (of request or response) MUST accept as equivalent
representations of an empty attribute group:
- attribute group tag with no following attributes
- expected but missing attribute tag
2. Identified a subset of the tag types (0-0xf) as being attribute group
tags (some of which have not yet be assigned); these should be handled like
attribute tags by any application/ipp recipient. The subset of tag types
(0x10-oxff) are "value tags".
3. A recipient of a request or response MAY skip all attributes in an
unknown group
4. Printer-uri and job-uri
MUST be on HTTP request line
MUST also be in operation attributes
5. Job operations MUST be supported with both
job-uri target
printer-uri target with job-id attribute
6. Create-job operation returns job-uri and job-id
7. Handling of localized text and names
Added two new data types:
localized text
localized name
both of there are represented as an octet string with four fields:
length of natural language identification
natural language identification (per RFC
length of text/name
content of text/name
8. Request ID added to all requests and responses
server returns received request-id in the response to the request that had
the request-id
client may match response with requests using the request-id; client is
responsible for management of request id numbering space; in HTTP, the
client can always use 0 as the request-id because HTTP guarantees responses
in the order requests are made.
9. Renamed 'data-tag' to 'end-of-attributes' tag
10. Added new out-of-band values for
no-value
unknown
11. Definition of status codes and operations moved to model document
No new issues were raised at the meeting
Mapping between LPD to IPP, Bob Herriot, the document was updated as follows:
1. added statement that this is informational and its intent is to help
implements of gateways between IPP and LPD
2. job-id
now both job-id and job-uri are available
allows job-id to be same as LPD job-id in relevant cases
3. job-originating-host was removed from IPP model; IPP-to-LPD must use
some other means to supply the 'H'(host) parameter.
4. job-k-octets was clarified to count octets in one copy, not all copies;
file size in lpq response does contain copies
5. Notification was removed from the IPP model; therefore support for LPD
email notification is not possible
6. For document format, SNMP Printer MIB enums were replace by (MIME)
media types
7. Authentication
job-originating-user replaced by job-originating-user-name
value is (explicitly) a human readable name
value comes from underlying authentication mechanism and the attribute:
requesting-user-name
No other issues were raised
Since all issues presented had a proposed solution that was acceptable to
the meeting; final copies of the documents, containing the proposed
resolutions, will be prepared and circulated to the mailing list by the end
of the week.
Assuming there are no significant comments received by Dec 18, the revised
documents will be transmitted to the IESG for processing before the end of
the year.
IPP Summary Paragraph
The standards track documents on the IPP Model and Semantics and the IPP
Protocol Specification and the informational documents on IPP Requirements,
IPP Rationale and Mapping between IPP and LPD were discussed. WG final
calls for these had either expired or were about to expire. Proposed
solutions to all known problems were reviewed (and, where necessary,
corrected) during the WG meeting. Unless some new issue arises, it is the
intent that final documents that include the proposed solutions will be
given to the IESG for final processing before the end of the year. With
this action, we consider the WG's charter to be fullfilled and do not
expect to meet at the next IETF meeting.
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com