Subject: IPP> ADM - DRAFT IPP WG meeting minutes at the IETF plenary, 4/1/98

From: Tom Hastings <[email-masked]>
Date: Mon, 6 Apr 1998 12:55:46 PDT

I've posted these draft minutes at:

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.