IPP> Preliminary Apps area report for Munich

IPP> Preliminary Apps area report for Munich

IPP> Preliminary Apps area report for Munich

Harald.T.Alvestrand at uninett.no Harald.T.Alvestrand at uninett.no
Mon Aug 25 12:35:19 EDT 1997


Hi,


below is Harald's report from Munich for the complete Applications Are.


regards,


Carl-Uno


----


Here's the preliminary area report for Munich. Comments welcome!


The original is HTML, btw; see
http://www.apps.ietf.org/area-report-munich.html if you want to see that.


I'm lacking reports from tn3270e, urlreg, ride-bof and schema-bof.


Have a good read!


                       Harald A




                     IETF MUNICH: APPLICATIONS AREA REPORT
                                       
   The most important and far-reaching things happening at this IETF were
   the reorganization of the Directory area and the debate on adding
   security into applications.
   
   The former seems to be well established, with the old directory groups
   folding as "finished", and the new groups being established to deal
   with LDAP extensions, LDAP deployment, schema registration and
   non-LDAP directories when the interest and clearness of mandate
   warrants.
   
   There are a few fundamental items that have to be addressed, however,
   including the question of whether we intend the directory work to
   produce a single, coherent namespace or just "tools for intranets".
   
   The security issue is not resolved. It is clear that we need protocols
   to have decent security mechanisms (which does NOT mean cleartext
   passwords!) as a mandatory to implement function, and it is equally
   clear that we do not have solutions that are known to satisfy a wide
   range of requirements, which makes wide deployment troublesome.
   Further work will need to be done here.
   
   There are currently 24 active Applications working groups, some of
   which are just waiting for Last Call completion before closing down;
   the area sponsored a total of seven BOFs at this IETF.
   
Summaries of working groups


  ACAP
  
   Reached concensus on all outstanding issues with base spec. CRAM-MD5
   will be mandatory-to-implement authentication mechanism. Will adopt
   anonymous mechanism and move with base spec. Agreed to spin off naming
   convention and registry for language sensitive comparator functions
   into a separate WG to attract the right people. Selected a fixed set
   of 4 dataset class specifications and 1 extension which are already
   published IDs to shepard on standards track prior to concluding the
   WG. Will meet in DC and plan on concluding early next year.
   
  APPLMIB
  
   The Application MIB working group meet on Monday August 11th to
   discuss the Application, and World Wide Web MIBs. Before starting
   discussion of these documents, an update on the status of our charter
   updates and requests for advancement of the System Application MIB to
   Proposed Standard Status were provided. The goal of this meeting was
   to complete reviews of both the WWW and Application MIBs so that final
   revisions could be sent out in about a month and a working group last
   call for both documents be issued before the next IETF. Rany Presuhn
   led a discussion of the Application MIB and changes that have been
   made since Memphis. The alignment of the MIB with the ARM efforts was
   also noted. Carl Kalbfleisch led a discussion of the WWW MIB and
   changes that have been made since Memphis. Some time was spend in
   discussion of how the WWW and Application MIBs tied to each other.
   Suggestions for a small number of additional objects were also made.
   Revisions to both the WWW and Application MIBs will be posted by the
   end of the first week in September.
   
  ASID
  
   The LDAPv3 last call completed and the group gave its signoff for the
   documents to go to the IESG. MIMEDIR and vCard were agreed to go to
   last call with minor changes. WHOIS++ templates and url was agreed to
   go to last call. Disposition of other drafts was discussed in light of
   the directory reorg. The group agreed to conclude as soon as the
   pending last calls completed.
   
  CALSCH
  
   CalSch had 2 meetings at Munich. The model document, the
   interoperability specification and the iCalendar document was
   discussed. All documents will be revised and posted for WG last call
   in the next 4-6 weeks. A draft document specifying the mail binding of
   the interoperability protocol will be posted in the same time-frame. A
   brief discussion of the use of LDAP to locate calendars and possibly
   free/busy time was concluded by asking for a clear problem
   specification. Security considerations for the interoperability
   protocol were discussed and with the help of Bob Mahoney and Paul
   Hill, will be systematically developed and incorporated into the
   documents. Chair noted the proposed 4-6 week schedule as too
   optimistic.
   
  DRUMS
  
   Reached concensus on outstanding issues with ABNF document, plan on
   finalizing it this month. Will aim to complete 821bis/822bis by next
   IETF, but may have to do one more cycle after that. Agreed to create a
   registry for email headers in a separate document.
   
  EDIINT
  
   EDIINT did not meet, its first set of documents being finished pending
   clarification on the situation with S/MIME.
   
  FAX
  
   The Internet Fax work group met on Wednesday, August 13. The updated
   charter and milestones were reviewed. The focus of the work group
   continues to be on developing standards for the "messaging" model of
   Internet fax, which will emulate commercial fax use. The current
   status of drafts for TIFF-F and TIFF-FX was reviewed. A proposal was
   presented on how to align the TIFF-F minimum set with the use of
   TIFF-F within WIDE. Two modifications to the values for the TIFF-F
   minimum set of fields were proposed to accomplish the alignment and
   there was a consensus to support the proposal. The group also agreed
   to use the simplified TIFF file structure per WIDE when using the
   TIFF-F minimum set. There was discussion during the rest of the
   meeting on three aspects of the fax messaging: addressing and Routing,
   confirmation of receipt and security. It was agreed that address
   content needs to be contained in the e-mail address and several
   alternatives were reviewed. There was consensus on the use of DSN for
   confirmation of receipt: the issuance of confirmation should result
   from the actual message delivery to the recipient and not before. The
   group also reviewed what levels of privacy and authentication would
   meet likely customer expectations for fax.
   
  FIND
  
   The FIND working group reviewd all the documents in the queue and
   agreed to go to last call as soon as was feasible. There are still a
   few problems with dealing with index objects as Mime types and the
   group agreed after an examination of RFC 2048 that they would have to
   create a new cip tree to handle different types of cip index objects.
   After this is apporved by the IESG, the documents will have to be
   updated, but we all thought the Washington DC meeting would be the
   last.
   
  FTPEXT
  
   FTPEXT did not meet
   
  HTTP
  
   The HTTP working group is making good progress toward completing the
   transition from Proposed to Draft Standard. At the meeting, we
   reviewed the open issues and made good progress on many of them. Some
   proposals for extensions to HTTP will result in 'Experimental' RFCs.A
   "HTTP/1.1 interoperability test" is being planned for testing
   implementations (browser, proxy, origin server) against each other.
   
   RFC 2109 (state management) has technical difficulties; it seems
   likely that we will recycle with a new draft that will be closer to
   current (interoperable) implementations, and with a revised (but not
   weakened) discussion of privacy considerations.
   
   Content negotiation has a broader scope than HTTP, and some of the
   work on it will result in work that may extend beyond HTTP-WG; others
   will result in Experimental RFCs. Our revised charter calls for being
   mainly complete with HTTP/1.1 by the December IETF, and with the
   possibility that the group may close or become dormant soon after.
   
  IDS
  
   IDS did not meet
   
  IPP
  
   The Monday session meeting was attended by about 35 experts and the
   Wednesday session by about 25. Total of 48 experts signed up on the
   attendence sheet. All of the WGs Internet-Drafts were open to review
   and comments. The Model & Semantics, Security, Protocol Specification,
   and LPD Mapping I-Ds still had a few open issues, which will be
   discussed further on the IPP DL. For the remaining documents, the only
   comment was that some aligment and updating is still needed to reflect
   changes in the other I-Ds. Highlights of the more important discussion
   points: a) In the Model & Semantics I-D Exact compression algorithms
   to be used. Instruction from Keith Moore not to reference Job
   Monitoring MIB, as this is not an IETF project. Instruction to also
   MIME types rather than MIB enums to reference document formats.
   Job-URI vs. Printer-URI plus Job ID; recent change critizised, further
   discussion needed. Order of result from Get-Jobs. Media-ready vs.
   media-supported. No clear agreement whether both are needed. b)
   Security I-D This document will be split over the Model & Semantics
   and the Protocol Specification I-Ds in next draft. Some further work
   needed on how client and server can always negotiate security
   features, even if no security is required. This problem is basically a
   generic HTTP problem, but a specific solution for IPP seem to be
   required. c) Protocol specification I-D Discussion of POST vs. a new
   PRINT method. Reasons for using PRINT over POST were not compelling.
   Will only be discussed if new strong arguments can be brought up in
   favor of a change. d) LPD Mapping Made clear that this is an
   INFORMATIONAL document only. Content considered as hints and example
   to implementors of gateways. e) General The chairs made clear that the
   intent of the WG is to move current I-Ds to final call in September.
   
  LSMA
  
   (Note: This has been culled from the minutes) Jon Crowcroft gave a
   brief history and restated the purpose of the WG. He suggested that
   the recent work, as illustrated by the draft i-d in the next section,
   represented a broader take on our work than the original membership
   and charter. The DIS (and share dealing networks) have timeliness
   requirements that suggest network provisioning/over-engineering or
   int-serv and rsvp deployment, which then make the requirements on
   reliability, timelienss, latency and so on easier to achieve in the
   application and middleware domains. The broader remit, in the "public"
   or "open" Internet environement today, without deployed int-serv/rsvp,
   means that tradeoffs need to be assimilated into the
   middleware/application levels. This is beyond our original intentionm,
   where we had a goal of pushing back on the other WGs in the IETF (
   (RSVP, Int-Serv, IDMR, ION, Mboned, and rcently, the IRTF RM group), a
   set of fairly well defined protocol scaling and performance
   requirements (as documented in the Scenarios and Limitations drafts.
   Mark Pullen agreed that the HLA had moved on from the specifics of
   DIS, and that perhaps this broader view was needed. 2. Presentation of
   draft-ietf-lsma-requirements-00.txt Peter Bagnall [Other Author: R
   Briscoe] Slides available at
   http://www.labs.bt.com/people/bagnalpm/lsma/munich.ppt [html and ppt 4
   version TBA on the WG email list] Expiration: 29 January 1998 BT 29
   July 1997 Taxonomy of Communication Requirements for Large-scale
   Multicast Applications Peter presented an overview of the excellent
   (well received) requirements i-d. There were a number of points raised
   by Dave Oran (regarding idea of fairness property of relative delays,
   errors and jitter seen by different receivers in heterogenous delivery
   - this is a nice definition of the problem where the parameters are
   defined sepcifically at each receiver (or sub set of receivers) and
   the differences defined as a seperate characterisation of requirement.
   Then it becomes application specific how we add new receivers and
   whether we degrade average performance, or allow lower quality
   reception to some, or reject new receivers somehow (at the middleware
   application level) if we cannot tolerate group degradation or a wide
   variation (or any variation) or support it threough resource
   reservation. The view was expresswed that the API should be able to
   express and controll all these (and opther) options for behaviour.
   Kirstein mentions Air Traffic Control as another strong requirements
   pull in this area (akin to the HLA/DIS one). The requirements on
   security for LSMA were briefly discussed - two nice applications were
   mentions: Games with large prizesm and database synchronisation -
   these put a lot of stress on current Internet Security mechanisms (in
   fact, large scale multicast with good secure timeliess to avoid
   _cheating_ appears to be a research topic, rather than something ripe
   for IETF standardizatio nwork - ed.] Tony Ballardie (IDMR co-wg chair)
   asked what appliocation requirement pushback on IDMR there was. There
   was a discussio nabout interaction between application performance
   requirements and tree types (symetric, shared/source based changes
   etc). Dave Oran and Mark Pullen commented that this was a key working
   area of the group so far, that we seemed to be moving up a laevel as
   well though. Christopher Bonatti asked about general APIs and the
   re-usability of techniques for LSMA. The WG Chair asked for feedback,
   and commented on the usefulness of the general notion (esp. the
   fairness v. heterogeneity, and scaling questions). Dave Oran commented
   on the "big picture" requirements to _reduce_ the black box nature of
   the Internet architecture. Ken Carlberg asked about the difference
   between Intranet and Internet requirements... 3. Document Deployment
   draft-myjak-lsma-scenarios-00.txt draft-pullen-lsma-limitations-00.txt
   It was agreed that these should go to WG last call between now and the
   next mee ting, and, if ok, then try to be progressed to informational
   RFC. 4. AOB None 5. Actions Jon Crowcroft to pursue with Area
   Director(s) whether LSMA should stay with current charter and wrap up,
   or complete current busniess at Washington IETF (40th!) and re-charter
   then with broader (or narrower) remit to include less DIS, and more
   general HLA and other LSMA (in the natural interpretation of the
   words) form along the lines presented in the
   draft-ietf-lsma-requirements-00.txt document.
   
  MADMAN
  
   MADMAN did not meet.
   
  MHTML
  
   MHTML met at IETF 39 with 28 participants and resolved all issues on
   its agenda. It was then decided that the MHTML specifications should
   be recycled at Proposed to replace the faulty proposed MHTML standard
   RFCs currently in circulation. The group then set Sept 30 as its date
   for moving the new documents to IETF Last Call. The new drafts will be
   posted as soon as possible for WG review and open discussion on the
   mailing list. All output of the meeting is subject to review and
   consensus evaluation on the MHTML Mailing List. MHTML WG plans to meet
   at IETF 40 in December.
   
  MIXER
  
   MIXER did not meet, having completed its work. The WG will be shut
   down once the last documents are processed through Last Call.
   
  NNTPEXT
  
   NNTPEXT did not meet, having gone through a change of chairs just
   before the IETF, and the new chairs concluding that nothing worthwhile
   could be done on short notice.
   
  PRINTMIB
  
   PRINTMIB did not meet
   
  RECEIPT
  
   RECEIPT did not meet; its output document is in IETF Last Call.
   
  URN
  
   There was no discussion re. existing documents (i.e., no one had any
   comments to offer). This is not surprising, as they are already a few
   revisions old. Therefore, they will be finalized and last-called. The
   primary issue of the meeting was namespaces -- what they are, who gets
   them, how they are registered, what it means to maintain them. There
   was a lot of discussion, tending towards a vague sense that an interim
   position will be to define baseline technical requirements, and
   require every potential URN namespace proposal to go through the RFC
   process. There is more discussion to be had here -- but the Namespace
   Requirements document editor felt he had heard enough consensus to put
   together a draft document that can be used to focus future discussion.
   The hope is still to aim for a December wrap-up of the group.
   
   A representative of CNRI presented the CNRI Handles work, and brought
   up questions about the reserved characters in the URN syntax. Handles
   may make a potential URN namespace, but he was referred to the working
   group's mailing list archive for the discussion re. the selection of
   reserved characters in the URN syntax (largely inherited from URI
   syntax).
   
  WEBDAV
  
   The WEBDAV Working Group met at the Munich IETF on Monday, August 11,
   1997, from 13:00 to 15:00. There were 54 attendees throughout the
   duration of the meeting. The meeting was chaired by Jim Whitehead, and
   notes were recorded by Del Jensen. The meeting began with a short
   overview presentation on WebDAV, which was followed by a presentation
   giving an overview of the design of the properties and collections
   functionality in the WebDAV protocol specification. After this
   presentation, the remainder of the meeting was concerned with
   discussing a series of open issues.
   
   During the issues discussion, the attendees were in favor of the
   following recommendations:
     * The DAV property identifiers (i.e., ";DAV/" + property URL),
       discussed in Section 2.4 of draft-ietf-webdav-requirements-01.txt,
       should not be used, and should be removed from the spec.
     * The SEARCH method (Section 2.6.5) should be renamed to PROPGET (or
       GETPROP or FINDPROP), and should be limited to retrieving just
       named resources from a given resource. There should be an
       additional mechanism for retrieving the names of all properties on
       a given resource without having to retrieve their values as well.
     * The property attributes "live" and "readonly" (Section 2.3.1,
       2.3.2) should not be returned with each property instance
       retrieval, but should instead be retrievable via a schema
       discovery mechanism (TBD) which would state the extent (i.e.,
       which namespace) and attributes (live, readonly) of a property.
     * The Depth header (and hence recursive semantics for method
       invocations) should be moved to a separate specification, which
       will proceed separately from draft-ietf-webdav-protocol. There was
       a suggestion to not use a Depth header, but to instead define
       separate functions (e.g., DEEPCOPY) for the recursive analog to
       existing methods.
     * Atomic locking of collections (Section 5.3.1.2 of
       draft-ietf-webdav-re quirements-01.txt) was discussed, and it was
       agreed that the requirement should stay as-is, that efforts should
       be made to satisfy this requirement in the protocol specification,
       but that there should be an awareness that this requirement might
       not be satisfied.
     * Authoring support for language variants was discussed, and no firm
       resolution was achieved.
       
Summaries of BOFs


  LDAPEXT BOF
  
   The group accepted the charter with a couple of additional items. Work
   items were split into four categories: access control, replication,
   APIs, and various extensions. Most of the existing proposed extensions
   were agreed to go to last call within a month. Editors were assigned
   for replication and access control requirements. API documents were
   agreed to be revised, shooting for last call by December.
   
  CHARSET BOF
  
   Harald presented the to be IETF policy for the handling of character
   sets, which briefly consists of the following; all information, in the
   format of strings for human consumption, transported using IETF
   protocols must have the character set and language declared. The
   default character set should be ISO 10646(Unicode) with UTF-8 as
   transport encoding. Language tags according to RFC 1766 should be
   used. A short discussion followed which made it quite obvious that
   there was rough consensus among the people in the room that this was a
   go thing.
   
  DIRDEP BOF
  
   The DIRDEP BOF was well-attended. After some discussion of the BOF
   agenda, the motivation for a DIRDEP WG, and prioritization of
   fundamental goals for such a WG, the BOF attendees indicated, via a
   rough concensus poll of the room, that they thought such a working
   group would be useful. Names of volunteers to edit most of the
   documents aligned with the goals agree upon by BOF attendees. The lack
   of volunteers for documents related to piloting activities suggests
   that this goal should not remain on the list of topics such a WG will
   address. The remaining fundamental goals (most important first) were:
   naming and interconnecting directories, schema-related issues,
   guidelines for client and server implementors, locating directory
   services, and help for people who deploy directories. The BOF
   attendees also indicated support for dealing with only LDAP deployment
   issues as well as changing the proposed WG name to LDAP Service
   Deployment (lsd). An updated charter will be developed and posted to
   the mailing list for discussion. Document editors will begin drafting
   documents after concensus is achieved on the new charter.
   
  AAARG BOF
  
   The AAARG BOF met Wed. evening and spent most of the time discussing
   the nature of the problem(s) as various participants percieved it and
   some desired solution characteristics. There was great concern that
   the total set of desired characteristics might preclude any solution,
   so any attempt to list the desired properties may have to prioritize
   them. There was interest in forming a WG to pursue this, although the
   BOF didn't get around to discussing a charter.
   
   A subsequent meeting of some participants Thurs. afternoon came to the
   conclusion that any further effort should:
     * look at specific application area protocols and list desired
       properties of an authentication mechanism;
     * try to describe the consequences of those properties;
     * try to examine available mechanisms to see how they satisfy the
       desired properties;
     * produce a document with recommendations for application protocol
       developers.
       
   It was suggested that a WG in the applications area should not attempt
   to produce a security protocol.
   
   Chris Newman and Randy Gellens volunteered to act as document editors,
   and Paul Krumviede volunteered to act as chair (or co-chair).
   
   The next action items are to produce the minutes and to compose a
   draft charter. Steve Hole will be working the former, and Paul
   Krumviede will attempt to produce a draft charter by the end of next
   week (the 22nd).
   
  HTTPNG BOF
  
   A BOF was held to see if there was interest in working on requirements
   for a next generation HTTP protocol. Over 50 people attended. After a
   general overview of the problem and discussion, a list of topics that
   might result in informational documents was produced, including: 1)
   survey of existing HTTP usage, 2) understanding usage and non-uage of
   HTTP, 3) how POST is being (ab)used in HTTP to tunnel other protocols,
   4) what administrative boundary controls are needed for a new
   protocol, 5) recommendations on firewall policy, 6) tunnelling of SSL,
   7) caching strategy, 8) HTTP use in proprietary systems, 9) general
   family goals. These might form the basis for deliverables in a working
   group charter. The attendees were polled asking how many might
   actually do real work to produce some documents; there seemed to be of
   order 8-10 people who claim they will be willing to contribute. A
   short discussion on schedule also ensued; best would be a schedule by
   the Spring IETF if possible, as other prototyping work is beginning
   now, and for input to have the most impact, it needs to be timely in
   nature. Charter and schedule bashing will occur on a mailing list to
   be set up as a result of the BOF.
     _________________________________________________________________
   
   
    Harald.T.Alvestrand at uninett.no
    
   Last modified: Thu Aug 21 14:38:35 1997



More information about the Ipp mailing list