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@uninett.no
Last modified: Thu Aug 21 14:38:35 1997