ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-ietf-minutes-980401.doc
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-ietf-minutes-980401.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ipp-ietf-minutes-980401.txt
The final minutes will be sent to the IETF later. Perhaps we should
review these minutes at the IPP meeting this week before sending them.
Tom
DRAFT
IPP Working Group IETF Meeting Minutes
April 1, 1998
Los Angeles, California
The meeting of the IPP WG at the IETF plenary was held on April 1, 1998
1:00-3:00 PM. The attendees were:
<to be added later>
1. Agenda
1) Requirements for notification
2) Directory features
3) Other future work
4) Area Directors questions about IPP
2. Requirements for notification
Carl-Uno presented the requirements for IPP notification:
Notification Requester
Notification Recipient(s)
Notification Content (events, attributes)
Notification Formats (human, machine)
Notification Timeliness (email, immediate)
Scott Isaacson reported that there is an LDAP I-D in WG last call on
dynamic attributes:
draft-ieft-asid-ldapv3-dynamic-07.txt
A requester can supply a "persistent search" on some dynamic attributes of
an entry and get results whenever they change. Thus LDAP is providing a
mechanism that could be used for notification. This approach scales, in
that the LDAP server is centralized, so that each client that wanted to get
notifications would register with the LDAP server once. Printers would
indicate events to the LDAP server once for each event, no matter how many
clients wanted results.
Scott also presented a summary of a survey of notification mechanisms that
have been developed in other arenas:
message queue (pull)
publish/subscribe (push)
Quality of Service (privacy, latency, authentication,
authorization)
Variants (durable, once, at least once, at most once)
Industry (OMG, Java, SNMPv3, email, SMTP MDN/DSN
Abstract Events:
Printer (error, warning, report)
Job (error, warning, report)
Concrete Events:
State Change (input tray < 50 sheets)
Concentrate on abstract events
An attendee suggested that we consider Tool Talk
has broadcast
has event filtering
Jeff Case, SNMPv3 developer, was present and indicated that SNMPv3 needed
the System Administrator to setup authorization for each subscriber.
Jeff Case and Keith Moore live near each other in Tennessee and will get
together to discuss SNMPv3 capabilities and usage for notification. It
would be good if a PWG member could attend their discussion as well.
2. Directory Schema
Scott Isaacson indicated that he and several other IPP folks worked with
the SLP editor to update the printer scheme intended to cover an IPP
printer and an LPD printer. The entries for each might look like:
service:printer:http://server.sun.com/cgi-bin/push-printer
service:printer:lpr://
The SLP STRINGL (L for literal) is identical to IPP keywords, i.e., no
translation to user's natural language.
One SLP entry is needed for each printer and security combination. So even
if an IPP Printer uses a single URI for both secure and regular, the SLP
directory will need two entries.
In SLP, the concrete protocol is http and lpr, respectively, and the
abstract protocol is ipp.
3. Future Work
Carl-Uno indicated that possible future work might include:
1) System Administrator functions
2) Extensions, such as dictionaries and per document attributes
3) MIME media types for each of the Printer MIB Interpreter Language
families that do not currently have MIME media types.
4) Extensions for Host-to-Device usage
3.1 MIME media type feedback
IETF feedback indicated that we should ask vendor's whether they wanted to
register their own Interpreter Language family, or wanted the PWG to do it
on their behalf. Keith Moore indicated that there is no problem with the
PWG registering something that a particular company owns, especially if it
is in common usage but that company isn't registering the Interpreter
Language family. On the other hand, if an Interpreter Language Family
isn't being used any more, there is no point in registering it.
ACTION ITEM (Tom Hastings): prepare a straw man list of Printer MIB
Interpreter Language family entries, indicating which already have MIME
media types, which the PWG wishes to register, unless the vendor responds
that they prefer to, and which the PWG has no interest in registering and
will leave to the vendor to do as it pleases.
3.2 Host-to-device extensions
Keith Moore indicated that the IETF might be willing to have a
host-to-device protocol on the IETF standards track. He'd like to hear
more about it.
4. Keith Moore's questions and feedback about IPP
Keith indicated that he is reading the IPP documents carefully. Because
the document is long, it is taking a while. He and the IESG will have some
responses in a few weeks. He has some questions that the group was glad to
answer:
1) What kind of extensions can be added without effecting interoperation?
Answer: new values to existing attributes, new Job Template attributes,
new Operation Attributes, and any Job Template attribute extension (if the
requester omits or supplies the "ipp-attribute-fidelity" = 'false').
2) He questioned the Create-Job "ipp-attribute-fidelity" operation
attribute being for all Job Template attributes at once. He thought that
the *implementation code* would be simpler and more extensible if fidelity
were specified per attribute.
Answer: We explained that we could compatibility add a Create-Job
operation attribute that explicitly listed Job Template attributes that
were compulsory (and/or one that listed Job Template attributes that were
non-compulsory), since unknown operation attributes SHALL be ignored and
returned in the response (with
'successful-ok-ignored-or-substituted-attributes' status code returned as a
status). Only if ignoring an operation attribute extension would adversely
affect new clients working with older servers, would we have to increment
the major version number of the protocol. This was an illustration of how
we could compatibly add attributes without impacting interoperability.
3) What job state should an IPP Printer return, if it sends jobs to a
device or server that cannot be queried?
Answer: return the 'unknown' value for a query of the job's
"job-state" attribute.
4) What were the IPP WG feelings about using the Post HTTP operation for
all IPP operations?
Answer: The meeting attendees discussed the issue of using Post versus a
new operation. Keith indicated that using a new operation would simplify
administration of firewalls. On the other hand, there were HTTP experts
present that said that the purpose of a Post operation was to update a data
base. The IPP create operations certainly fit that description. However,
the IPP query operations (Get-Job-Attributes, Get-Printer-Attributes,
Get-Jobs), aren't updating a data base. There was no conclusion for or
against using HTTP Post (or a mixture of Post and Get) or a new operation.
As before, there are pros and cons.