IPP> ADM - Minutes from Munich

IPP> ADM - Minutes from Munich

IPP> ADM - Minutes from Munich

Carl-Uno Manros cmanros at cp10.es.xerox.com
Wed Sep 10 20:02:22 EDT 1997


Hi,


at long last I have now pulled myself together to edit up the minutes from
Munich.  My thanks to Randy and Scott who took the actual notes during the
meetings.  I have gone over their notes and edited out the things that were
not controversial, to mainly leave in the things that need further action.


Hope I did not leave out anything of importance.  Here is the text:



---


IETF-39 - Minutes from the IPP WG sessions 
on Monday August 11 and Wednesday August 13, 1997
==================================================================


Chairs: Carl-Uno Manros and Steve Zilles


The Monday session meeting was attended by about 35 experts and the 
Wednesday session by about 25. A total of 48 experts signed up on the 
attendance sheet.


All of the WGs Internet-Drafts were open to review and comments.


Session on Monday, August 11 (minutes taken by Randy Turner)
============================
Carl-Uno Manros opened the meeting and reviewed the agenda.


The I-D: <draft-ietf-ipp-req-00.txt> Requirements for an Internet 
Printing Protocol 


   was briefly introduced.  This document will need some updating 
   to align with more recent documents, otherwise no comments.


Steve Zilles then briefly provided a quick overview of IPP,
specifically the object concept. 


The I-D: <draft-ietf-ipp-rat-01.txt> Rationale for the Structure of 
the Model and Protocol for the Internet Printing Protocol 


   was briefly discussed, limited to the model aspects, without any 
   substantial comments.


The I-D: <draft-ietf-ipp-model-04.txt> Internet Printing Protocol/1.0: 
Model and Semantics 


   was introduced by Scott Isaacson.  This is the key document for 
   IPP and still contained a number of open issues. Scott had prepared 
   proposed resolutions to all the issues flagged, based on WG input 
   since the draft was published.  Most of the proposed resolutions 
   were uncontroversial, but the following raised some discussion:


1. Compression of IPP messages


    This issue is OPEN. The WG is looking at other standards and
    existing enumerations for compression algorithms.


2. Alignment with Job Monitoring MIB


   job-k-octets, job-impressions, and job-media-objects will be
   aligned semantically with the Job Monitoring MIB.


   One note about the Job Monitoring MIB. Keith Moore, Area Director 
   for Applications, noted that there is no formal IETF working group
   chartered for the Job Monitoring MIB effort. Further, there may be 
   problems with IPP documents achieving "proposed" status if IPP 
   documents reference such other documents. He reiterated that the 
   Printer Working Group had submitted an extension to the Printer MIB 
   working group's charter to include the Job MIB, but that the request
   had not been processed by the IESG, so there may be a problem here.


3. Human Language and Character Set


   IPP mandates UTF-8 for application/ipp messages. HTTP Accept-Headers
   will be used for human-language attributes. Questions from the
   audience asked about whether the WG had considered the use of 
   an updated Unicode spec. UCS-4 which is currently being proposed.
   Scott Isaacson implied that the WG is open to suggestions as to
   what standard should be applied here. The basic theme echoed by
   Keith Moore was to try and follow Harald Alvestrand's document, and
   if better methods are suggested, the IESG will keep an open mind.


4. Job-URI attribute


    "A lively discussion ensued". Basically, it was agreed that
    this issue is still OPEN and will be discussed on the mailing
    list.


5. Use of "Conditionally Mandatory" in IPP documents.


    The I-D will be re-edited to focus on what must be implemented 
    in order to realize certain specific functional components.
    Keith Moore reflected on current IETF documents for keywords
    such as MUST, SHOULD, MAY, etc. and that the WG should try and
    follow the IETF guidelines and best current practice with
    regards to such conformance/compliance vocabulary.


6. Use of MIME types for "document-format"


    Currently, the model document specifies the use of Printer MIB
    enumerations for specification of document-format. In addition,
    at a recent PWG meeting, it was agreed that enumerations for
    PDF and HTML ought to be added to this list. 


    Upon hearing the proposed alignment with the Printer MIB for
    these values, "a lively discussion ensued".


    It was the opinion of Larry Masinter (chair of HTTP WG), Keith
    Moore, and most of the IETF audience that alignment with the
    Printer MIB was a mistake, and that we should focus on sticking
    with MIME-type specifications.


    Further, Keith Moore went on to say that the current draft of
    the Printer MIB was "broken", and that he is seriously
    considering delaying advancement of the Printer MIB draft until
    this (and possibly other) issues are addressed.  Keith did not
    go into any detailed analysis of why the MIB was broken, but
    seemed to suggest that there were more than one reason why it's
    broken. He went on to say that its possible that (ironically)
    the IESG might suggest to the working group that the Printer
    MIB should align itself with the MIME-types and change the way
    that interpreters are enumerated in the MIB. He suggested that
    the group should consider strings, and not enumerations, to
    specify these types (i.e., MIME types). Keith was pretty adamant
    on this issue and would have continued discussion, but Steve Z.
    and Scott suggested that discussion on the Printer MIB was
    not appropriate at an IPP WG meeting.  


7. Server Timeout


    The printer will abort a job after some server-configured 
    inactivity timeout. If some documents had already been printed,
    the rest of the job is canceled. Larry Masinter questioned
    why IPP operations could not be "re-tried" if a failure occurred.
    Steve Zilles responded that there might be idempotency problems
    with operation retries. More discussion on the mailing list 
    should be done.


8. Version Numbers


    Given the number of HTTP WG members in the room, "a lively
    discussion" on capability negotiation and version numbers
    ensued. It is very likely that some combination of versioning,
    and capability negotiation will be required before gaining
    IESG acceptance.


9. Color


    Will remain a boolean, "color-supported'. Leave it to the PDL
    to handle other color model and capabilities requirements.
    Some questions by the audience questioned the usefulness of a
    "boolean" to specify color capabilities. Keith Moore said that
    he would like to see the specification of color capabilities
    more fleshed out than just "yes, this device supports color".
    Larry Masinter also suggested that in order to curb the 
    displeasure with such a "boolean" specification of color, that
    maybe the WG should remove this and just do a complete color
    capabilities model in a future version of IPP. He suggested that
    either IPP should do color (the right way), or not at all. 
    After a brief rationale statement by Scott Isaacson and Steve
    Zilles for the boolean color-supported, both Larry and Keith
    seemed to understand why, but still were not crazy about the
    inclusion of color, without the WG "doing it right".


10. Date and Time


    "time-since-xxxx" attributes will be in "seconds" (and OPTIONAL).
    A MANDATORY "printer-up-time" will be added to the spec. and
    will essentially reflect the MIB-II "sysUpTime" object. Larry
    Masinter questioned why a printer "end-user" would care about
    how long the printer had been "up", since IPP 1.0 is basically
    targeted for end-users. He further questioned why the value
    was mandatory. The WG implied that since MIB-II sysUpTime was
    mandatory, that no undue burden should be placed on IPP
    implementations to support it. 


11. Formatting Attributes


    The WG will work on a proposal for "page-range" and 
    "page-orientation" attributes.


12. Order of Jobs returned by "Get-Jobs"


    OPEN.


13. Event Notification


    The WG has an action item to specify event notifications. They
    should be machine-readable.


14. media-ready vs. media-supported


    OPEN. Some implementation require this distinction. Especially
    server-based implementations of IPP. It was suggested that
    media-supported be dropped and only support for media-ready
    should be supported, since this would apply to all IPP
    configurations.


The I-D: <draft-ietf-ipp-dir-schema-01.txt> Internet Printing Protocol/1.0: 
Directory Schema 


   was introduced by Scott Isaacson.


    More work needs to be done to bring the current directory schema
    documents up to date with the current Model document. One of 
    the members of the Service Location Protocol WG mentioned that
    they already have started working on a schema for Printing Class
    applications within their WG, and that input from the IPP WG
    is "very welcome" at this stage. Scott Isaacson stated that
    such cooperation should definitely take place.


Session on Wednesday, August 13 (minutes taken by Scott Isaacson)
===============================


Carl-Uno Manros opened the meeting and presented the agenda. 


The I-D: <draft-ietf-ipp-rat-01.txt> Rationale for the Structure of 
the Model and Protocol for the Internet Printing Protocol 


   was introduced by Steve Zilles and then briefly discussed, limited
   to the protocol aspects, without any substantial comments.


The I-D: <draft-ietf-ipp-sec-01.txt> Internet Printing Protocol/1.0: 
Security 


   was introduced by Carl-Uno Manros.  The following comments and
   discussion followed:


1.  Scope of security in IPP


    What is in and what is out of IPP? How much can we rely on getting 
    from the numerous IETF security projects and what do we have to do 
    ourselves?  Should not the HTTP group be responsible for security
    needed for HTTP?  How is the use of TLS with HTTP specified?  
    HTTP seem to ignore further standardization of Basic Authentication
    and are only progressing Digest Authentication.


2.  Status of IETF security standards


    There is an interest from IPP to use TLS for secure transmission, 
    but the TLS standard is not yet finished.  Can SSL be used instead?
	
3.  Secure and insecure communication with the same IPP Printer


    We should allow for the protocol to have some kind of negotiation 
    mechanism. One suggestion was to always use TLS, allowing the client 
    to be configured to run with TLS NULL, NULL, NULL.


It was also stated that the content of the current document will be
divided up between the IPP Model & Semantics and Protocol Specification 
document in the next round of editing.


The I-D: <draft-ietf-ipp-protocol-01.txt> Internet Printing Protocol/1.0: 
Protocol Specification
                     
   was introduced by Bob Herriot.  The following comments and
   discussion followed:


1. Does IPP need to worry about the fact that some server implementations 
   do not pass HTTP headers to the back end processes (CGI)?  
   No, this is an implementation problem.
	
2. Accept headers


   Accept-charset is irrelevant
   Accept-language is relevant
   Accept-encoding probably (might be)


3. We need to make sure that the IPP mapping works with generic HTTP 
   clients, HTTP origin servers, and HTTP proxy servers


4. Why POST over new method PRINT?


   PRO POST
	It is there
	It works
	It really doesn't matter


   CON POST
	Harder for proxy server to differentiate
	Better performance with native method
        POST was intended to be a "big hole"
        WEBDAV uses XML and new methods     


   RESOLUTION: Use POST for all of the reasons identified and move on. 


5. Why not use some other transport, such as SMTP?
		
   IPP has been designed not to prevent this, however no interest in the 
   WG to make such other mappings.
   Additional mappings could show a mapping of multiple operations in one 
   MIME component, or could use Internet Fax extensions.
	
6. Content negotiation should be more symmetrical (client telling server, 
   server telling client)


The I-D: <draft-ietf-ipp-lpd-ipp-map-01.txt> Mapping between LPD and IPP 
Protocols
                 
   was introduced by Bob Herriot. The following points were discussed:


1. How does mapper support "host"?


   IPP to LPD; set H to mapper host
   LPD to IPP, ignore H


2. job-k-octets semantic change between IPP and LPD (which includes copy
count?).
		Just do the mapping


3. Move to Job-ID vs. Job-URI


   Needs to be resolved on the discussion list (see Model & Semantics
discussion 
   earlier).
		
4. Should IPP pick a format for queue status or make it dependent on each LPD 
   implementation? Further discussion on the DL.


   a. ignore the problem
   b. pick a format
   c. make it MUST or SHOULD
	
5. This mapping document is an INFORMATIONAL RFC, not an IMPLEMENTATION RFC
	
6. Should DVI, ditroff, or troff should be added as document-format types?  
 
   If we make them MIME types, then anyone can add them that wants them.


7. Open issue about mapping LPD to IPP error codes.


The chairs made clear that the intent of the WG is to move current I-Ds to
final 
call in September 1997.


-----


El Segundo, September 11, 1997 - Carl-Uno Manros - IPP Co-chair


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




More information about the Ipp mailing list