Notes for Sept 9 WG meeting (by Dennis Hamilton)

Interim WebDAV Meeting
2002-09-09 Session

Held at the University of California at Santa Cruz
during the September 2000 interoperability-confirmation tests

Last Updated 2002-09-10-13:05 -0700 (pdt)


iminaries>  and Preliminaries

Action <file:///A:\2002-09-09-WebDAV.htm#ActionItems#ActionItems>  Items

1. Agenda <file:///A:\2002-09-09-WebDAV.htm#Agenda#Agenda> 

2. ACL
nStatus>  Status

ionStatus>  Status

4. Property
ion>  Registration

5. RFC 2518 bis <file:///A:\2002-09-09-WebDAV.htm#2518bis#2518bis>


Attendance and Preliminaries


*	Lisa Dusseault, co-chair 
*	Jim Whitehead, co-chair 

[enter names from list circulated in the meeting]

We met upstairs from the Interop event, starting shortly after 3pm.

Dennis Hamilton agreed to take notes for this session.

Dan Brotsky requested that the group acknowledge the contribution that
Jason Crawford has made in managing the issues list.  There was nodded

At the end, based on the amount of discussion and speed on the agenda,
it was agreed to change the September 10 session from 3-6pm to 1pm -

The session ended promptly at 6pm.

Action Items

[who?] Communicate the working group's appreciation to Jason Crawford.

Dennis Hamilton: turn over notes from this session before he leaves on

Lisa Dusseault: 

*         Provide links to her latest drafts of 2518bis for people to be
able to review. [done by e-mail to the list, 09-10] 

*         Circulate paragraph on what behavior for PropFind for members
of a collection MUST be implemented. 

Jim Whitehead: Contact Ned Freed about the workings of registration
procedures via IETF/IANA (re feasibility for use in Property
ion>  Registration)

Dan Brotsky: Send out a note on clarifying lock
discovery and that this not be defeated by servers refusing to disclose
the necessary information for lock discovery to be meaningful.

Ilya : Write the paragraph on forcing
ation>  authentication that will go to the list and into RFC 1518 bis.

1. Agenda

In creating the agenda, Lisa remarks that the working group needs to
review its charter.  We agreed to carry this to the September 10

Also there is a topic on Interoperability Process and what does 2 by 2
interoperability mean?  This was added in under the RFC 2518 bis
<file:///A:\2002-09-09-WebDAV.htm#2518bis#2518bis>  discussion.

1.      Kudos for Jason
<file:///A:\2002-09-09-WebDAV.htm#ActionItems#ActionItems>  -  

2.      Status of the ACL
nStatus>  Specification and of DASL
ionStatus>  (Search) 

3.      Property Registration (15 minutes) 

4.      RFC 2518 bis <file:///A:\2002-09-09-WebDAV.htm#2518bis#2518bis>

o        Start with the ones on the board in the interoperability work 

o        Litmus tests 

o        Continue with others 

2. ACL Status

The ACL Status was summarized by Jim and Lisa:

1.      The specification is in the hands of the Area Director for

2.      The review process is slow and WebDAV is in spin-wait until it
is sent back for changes or posted as approved. 

3.      All known issues have been resolved in the document that is
under review. 

3. DASL Status

The DASL history was reviewed.  The DASL working group had been
disbanded after going inactive. Since then, Julian Reschke has been
maintaining the specification and posts versions as Internet Drafts,
providing an informal process on the side of WebDAV.

In the discussion:

1.      Lisa mentions that there are open problems around character sets
and languages that DASL will also bump into.  She provided a little
background on how difficult it is to make a successful specification
anywhere that there are character strings intended for human
interpretation.  Sorting is also a big concern, because collating
sequences have such variability at the international level. 

2.      The topic of how to advance more rapidly was raised, but no
suggestions came forth, beyond to continue encouraging Julian and
promote people working on it. 

4. Property Registration

Jim Whitehead provided an overview of the situation, raised by

*         So many properties being defined in 2518, and the allied
specifications, etc. 

*         People wanting to have a way to add properties and have them
be standardized in some sense 

Dennis provided some background on how this became a project on AIIM
(that he has been sandbagging for well over a year now).  The purpose is
provided on DMware site project description

Dennis summarized the levels that seem to be of concern, and he came to
ask which level do people see as appropriate, and if that is the answer,
what is the problem that is being solved: 

*         That a property identification is taken and has been used 

*         That a property identification has been taken and the
authority on the property is so-and-so. 

*         That a property identification has been taken by so-and-so and
here is how to find a description of the property intended for human

*         That a property identification  ... and here's a description
intended for computer processing 

Dennis assumes that the last bullet is over the edge for the WebDAV
community, although it matters for managed documents when we look at
metadata discovery requirements and even model discovery requirements
(e.g., finding the rules for playing nice in manipulation of coordinated
WebDAV resources).  Dennis has been operating on the assumption that
there is room enough in WebDAV  for there to be private or
specific-community (i.e., vertical) agreements on properties (just like
there are so many flavors of XML agreements).  But there is also a sense
that some fundamental registration approach be agreed in the overall

Jim Whitehead described his initial assumption that something like IANA
MIME-type registration could work for WebDAV properties.  Dennis said
that the requirement to put MIME-type specifications through the
Informational RFC process seemed particularly heavyweight and he thought
the community would want something easier to use.

In the discussion, it was suggested that once an overall procedure is
established, making additional submissions could be as simple as filling
out a form and then going through a registration process that gave rise
to an Informational RFC by a very simple process, along with appearance
on an IANA registry.  One benefit of using an IETF/IANA scheme is the
persistence of the IETF repository of rfcs, and its likely long-term
stability in contrast with anything that is maintained separately or by
a small group.

There was inconclusive discussion on how to follow up with IETF/IANA on
this.  Dennis said he had enough to put something on the list and widen
the discussion. Jim Whitehead is going to do check with Ned Freed on the
IETF/IANA protocol for having their agreement to register property

It is also felt that the registry is needed for even the DAV:
properties, because there are so many and their status needs to be
maintained over time.  The registry mechanism is not exclusively for the
DAV: properties, but it is important to handle them.

The following explosion of topics was identified.  It became clear in
the discussion that creating a registration procedure and (especially)
agreeing on what to register about a property will push back on places
where the property model is not adequately or clearly specified.

1.      Registry for the DAV namespace and the rules for what are these,
which ones are being deprecated, and what to do with them.  The registry
is something that can be used to normalize the DAV namespace.   

2.      What to do about provisional, anticipatory, and experimental
ones that don't end up in a final specification. 

3.      Discussion of grandfathering and/or deprecating the stray DAV:
properties that aren't in the specification, or put (some) in the

4.      Discussion about DAV: as a reserved namespace and the business
of the URI of the namespace, DAV: as a URI prefix, etc. 

5.      Say what are the rules for the DAV namespace. 

6.      Dan Brotsky: The model for properties is not circumscribed
enough, but people want to know what the rules are --  

o        when can I be sure that a property will be dead,  

o        how I can find out if values have changed, and  

o        can the server enumerate this or that about the properties.   

o        The property model may not be tight enough.  There is also the
problem of the syntax of the values. 

7.      Jim Whitehead thinks that property access (read)
interoperability can come with some ease and property creation/setting
interoperability might take more.  We might want to take the easy case

8.      Jim Whitehead knows Ned Freed and this game would then work.
Then for us the question is what does the form look like and what kind
of things might not be OK to handle this way.  Needs to be discussed on
the mailing list. 

9.      What are the reasonable questions to answer on a property
registration questionnaire: 

o        Protected versus writable 

o        Name and namespace 

*         XML 1.1 recommendations on element and attribute names.  Any
XML language rules work 

o        Static or dynamic 

o        Live or dead 

*         Great discussion about the distinctions live and dead, etc.,
and what is going on here. 

o        authority defining the property 

o        syntax of values 

o        under what conditions will the property change 

o        configuration versus not 

o        syntax enforced versus not 

o        is it searchable? 

o        responds to PROPFIND ALL? 

o        cacheable? 

o        dependencies among properties 

o        notes - things not covered in other questions 

o        resource type that property defined on 

*         collection only? 

o        conditions under which property can be written 

o        terms and conditions of use, legal conditions 

o        questions about permanence of properties and invariance,
invariance of the definition - we must take a stand on this one way or
the other. 

o        inheritability -- it is a form of liveness 

o        date of definition 

o        software it appears in - who implements it 

o        review authority and acceptance of the definition 

*         DAV namespace properties 

*         Use of namespace 

*         Namespace registrations? 

10.  The work on this will drive tightening of the property model. 

11.  This list may not be complete, and what do we do?  Do we understand
enough to have a strawman list. 

12.  Dependent properties? 

13.  Semantics and syntax of the property 

We ended declaring that we had done enough (in much more than 15

5. 2518 bis Issues

5.1 Meta-discussion

We had a meta-discussion on the word "bis."  Lisa had assumed the word
is German.  Dennis thought it was French (because the ISO uses it).  We
concluded that this usage is probably from Latin.  [Checking a very
laptop translator dictionary: In Italian it is an adjective for "second"
and it is also used for "encore."  In French it has that and the sense
of "repeat" as well as being an adjective for a color (grayish-brown)
and an adverb for "twice."  In German it is the preposition for "until,
by, through." --dh:]

5.1.1 Interoperability Process

This conversation was in "bullets":

*         Need a quick breakage list 

*         Availability of free software (regarding testing and

*         More clients in test 

*         Always-online clients 

*         Litmus and Litmus-like test suites available as clients 

*         Ways for servers to request tests from a client. 

5.1.2 Defining 2 by 2 interoperability

Question on what the IETF community definition is for this.  More

*         WebDAV has done due diligence in that regard 

*         As much as has been done, the interoperability story isn't
that great 

o        pairwise confirmation of features is not the same as pairwise
confirmation of the feature set, and this leaves lots of disconnects 

*         Let's not make more work with the IETF 

*         But let's get to where it says WebDAV  on the box means there
are not any material problems that an user would have to deal with 

5.2 "Board" Issues

During the interoperability sessions on the first day, a number of
topics for breakage came up.

5.2.1 Breakage Involving Presumably-Resolved Issues

These are issues that are thought to have been resolved and
disambiguated in the specification, yet implementations are still
deviating.  These are areas where more is required, either in being
clear or in having more to a facility for it to work properly. Having lock information be discoverable

Clients need untampered ownership of a lock that the server does not
monkey with it, and in bis, servers are not supposed to muck with the
owner value, so what about servers being free to withhold elements of
lock discovery?

Either get all the information but be forbidden to discover the lock.

Brotsky to send out a note on this one. How can clients force authentication?

The problem of not being made to authenticate until trying to write.
This leaves users in the awkward position of doing lots of work and
then, when it is time to put something, an unanticipated authentication
requirement comes up.

Question about how to force authentication at the beginning of a
"session" so that user doesn't do a lot of work and then be confronted
with an authentication requirement

Lisa likes the idea of using the header and working there.

Also, don't want to break the practice of forcing users to be
authenticated from the get-go.

Options that force authentication to write are desired.  Methods have
special fire-wall implications, and we got lost in hilarity about
methods prefixed by X-.

We fell back to Options.  

Brotsky offered the example of PROPPATCH of a read-only property, as a
roundabout way to provoke authentication.

We came  back to Options.

Prefer something like the connect specification.  Want to ask Julian to
write the rfc.  Ilya will write the paragraph that goes to the list and
into the spec. Collections without the slash

All places where a URL is returned, if it is for a collection, the
specification says "should" provide the slash, not must.

When you say PropFind, the returned URLs should always have a slash
after the segment for a collection.  This segued into the overall
problem of PropFind responses for collections: PropFind Responses for Collections

Are relative URLs allowed in propfind responses?

Jim W: So is this a spec language issue or is something needed in the

Brotsky: Servers must not be confusing to clients and we need to see how
to do that.  We probably ought to do relatives more, it needs to be
relative to the URI in the request: relative, absolute, or fully
qualified (anything not fully qualified is considered a relative URI in
the specification) -- we have to be really careful about the
specification language

Difficulties are with the client handling the different cases of what
comes back.  

Brotsky says that servers must use proper internal URIs, and it is
strictly defined, in terms of internal member URI.  The question is can
the top level URI be different than the one the client offered.

Lots of discussion on prefixes of URIs, how to get around this.  And
whether servers are allowed to optimize the client's future behavior.
Brotsky wants the server to be gentle with the client.  In the case at
hand, the client is asking "tell me what the internal members of this
collection are."  If the server can return whatever it wants, the client
is under a terrible burden.

Lisa has some language for a MUST to add to the specification based on
presence of a content location header.

In the absence of a content location header, there is discussion about
not having the same level of MUST-ness for the request URL.

Conversation about what a client is, and Brotsky says that HTTP says.
Needs more discussion, and RFC 2518 may need to be more emphatic that it
is relying on the HTTP 1.1 definition of client and have people be clear
about the implications.

5.3 New Open Issues

We didn't get that far.  The September 10 meeting will begin at 1pm and
continue to 6pm to ensure coverage of more issues.


Received on Sunday, 15 September 2002 15:10:19 UTC