A brief summary of topics discussed at the 6/9 protocol teleconference:
Attendees:
Carl-Uno Manros
Scott Isaacson
Peter Zehler
Harry Lewis
Tom Hastings
Randy Turner
Keith Carter
Roger DeBry
* Steve Zilles' proposal for adding an attribute data type field was
discussed. The call participants
agreed that it was possible to achieve the same level of
extensibility by having an external
registry (possibly IANA) to catalog attribute names and attribute
types, but the group felt that
including the attribute type in the actual wire encoding served no
benefit.
* A couple of problem issues with the latest IPP draft by Paul Moore
were discussed. One was the
fact that one of the attribute names (Job-Originator) was named
differently than the equivalent
attribute in the model document. The other was the fact that the
'document-format' attribute used
PDL enumerations from RFC 1759, unlike the model document which
specifies MIME tags.
One other issue concerning this draft was the fact that the document
self-references itself as IPP1,
or IPP level 1. This could be misconstrued by readers of this
document as version 1 of the IPP
protocol, given that a version 1 and version 2 of IPP are mentioned
by the IPP model document.
Someone reading the model document, followed by the SWP/IPP document
by assume that IPP1
documents version 1 of the protocol.
Overall, it was hoped that the document would be rolled into a single
IPP-over-HTTP document
to be delivered to the IETF as a proposed standard. As a result of
the last IETF plenary meeting
in San Diego, it was felt that any more than one protocol document
submitted would not be
favorably received.
* There was some brief discussion on reconciling the IPP model document
with the model and
semantics of both the Job MIB and the Printer MIB. Since these are
all products of the PWG,
ideally they should speak from the same model and give basically the
same 'message' to the
printing industry.
* Also, several other IETF standards-track protocols are being
co-developed with a companion
MIB document that identifies manageable objects that can be remotely
configured via SNMP.
At a minimum, we should try to identify manageable objects that
administrators might want to
access for a IPP server for configuration and monitoring of an IPP
service. No volunteers
stepped forward when a query was made to check interest (big
surprise, huh?)
Randy