2.1.10 WWW Distributed Authoring and Versioning (webdav)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-10-21

Chair(s):

Lisa Dusseault <lisa@osafoundation.org>
Joe Hildebrand <jhildebrand@jabber.com>

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

Applications Area Advisor:

Ted Hardie <hardie@qualcomm.com>

Mailing Lists:

General Discussion: w3c-dist-auth@w3.org
To Subscribe: w3c-dist-auth-request@w3.org
In Body: Subject of subscribe
Archive: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/

Description of Working Group:

The goal of this working group is to define extensions to the Hypertext
Transfer Protocol (HTTP) that enable remote collaborative authoring of
Web resources. This is the third charter for
this Working Group, and does not include items
that have already been completed by this Working
Group (base WebDAV Proposed Standard, ordered
collections extension, and access control
extension).

When the WebDAV working group was initially formed, it was reacting to
experience from circa-1995/96 HTML authoring tools that showed they
were unable to meet their user's needs using the facilities of the HTTP
protocol. The observed consequences were either postponed introduction
of distributed authoring capability, or the addition of nonstandard
extensions to the HTTP protocol. These extensions, developed in
isolation, are not interoperable. The WebDAV Distributed Authoring
Protocol, RFC 2518, addressed these concerns by providing facilities for
overwrite prevention (locking), metadata management (properties), and
namespace management (copy, move, collections).

Despite their utility, several important capabilities were not supported
in the initial Distributed Authoring Protocol. It is a goal to create
protocols to support these capabilities:

* Referential Containment (Bindings): The WebDAV Distributed Authoring
Protocol has unusual containment semantics where multiple containment
is allowed, but not supported by any protocol operations, yet
container deletion assumes inclusion containment, deleting the
container and its members. Most object management systems provide
full support for referential containment, and have delete semantics
that
only remove the container without affecting contained objects.

* Namespace Redirection (Redirect References): HTTP, via its 301 and
302 responses, supports namespace redirection where a request on one
URL is returned to the client with instructions to resubmit the same
request to another URL.

As with most application layer protocols, implementation and field
experience on the WebDAV Distributed Authoring Protocol has highlighted
many issues that should be addressed as the protocol is advanced from
proposed to draft standard status. Some of these issues will require
additional deliberation within the WebDAV working group.

NOT IN SCOPE:

The following items were initially identified as being out of scope for
the WebDAV working group, and continue to be such:

* Definition of core attribute sets, beyond those attributes necessary
for the implementation of distributed authoring and versioning
functionality

* Creation of new authentication schemes

* HTTP server to server communication protocols

* Distributed authoring via protocols other than HTTP and SMTP

* Implementation of functionality by non-origin proxies

Deliverables

The further output of this working group is expected to be these
documents:

1. A Bindings Protocol, providing a specification of operations
supporting referential containment for WebDAV collections. [Proposed
Standard]

2. A Redirect References Protocol, providing a specification of
operations for remote maintenance of namespace redirections, and the
interaction of these redirections with existing HTTP and WebDAV
methods. [Proposed Standard]

4. An updated version of WebDAV Distributed Authoring Protocol that
resolves known issues with the protocol. [Draft Standard]

At present, the Binding Protocol and Redirect Reference protocols have
been through a WG last call but major changes were made and another
WG last call seems advised. The revision of the WebDAV Distributed
Authoring Protocol has been started.

In addition to the IETF Internet-Draft repository
(http://www.ietf.org/ID.html), the most recent versions of these
documents are accessible via links from the WebDAV Home Page,
(http://www.ics.uci.edu/pub/ietf/webdav/), and on WebDAV Resources,
(http://www.webdav.org/).

Goals and Milestones:

Done  Revise Access Control Protocol document. Submit as Internet-Draft.
Done  Meet at Pittsburgh IETF. Discuss Access Control Goals and Protocol documents. Discuss issues in WebDAV Distributed Authoring Protocol
Done  Revise Access Control Protocol document. Submit as Internet Draft.
Done  Revise Access Control Protocol, and Access Control Goals documents. Submit as Internet Draft. Begin working group last call for comments.
Done  Revise WebDAV Distributed Authoring Protocol. Submit as Internet-Draft
Done  Meet at San Diego IETF. Hold a review of the Access Control Goals and Protocol documents. Discuss comments raised during working group last call for comments. Discuss issues in WebDAV Distributed Authoring Protocol.
Done  Submit revised Ordered Collections protocol as Internet-Draft. Begin working group last call for comments.
Done  Meet at Minneapolis IETF. Discuss issues in WebDAV Distributed Authoring Protocol, and WebDAV property registry.
Done  Submit revised Ordered Collections protocol as Internet-Draft. Submit to IESG for approval as a Proposed Standard.
May 04  Revise Binding draft, submit as internet-draft. Begin working group last call.
Jul 04  Revise Redirect references draft. Begin working group last call.
Sep 04  Revise Binding as necessary, submit to IESG for approval as Proposed Standard.
Oct 04  Close more open issues in new draft of revised base protocol (RFC2518bis). Consider WG last call.
Oct 04  Revise Redirect references as necesssary, submit to IESG for approval as Proposed Standard.
Dec 04  Submit revised base protocol (RFC2518bis) to IESG for approval as Draft Standard.

Internet-Drafts:

  • draft-ietf-webdav-redirectref-protocol-10.txt
  • draft-ietf-webdav-rfc2518bis-06.txt
  • draft-ietf-webdav-bind-07.txt
  • draft-ietf-webdav-quota-04.txt

    Request For Comments:

    RFCStatusTitle
    RFC2291 I Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web
    RFC2518 PS HTTP Extensions for Distributed Authoring -- WEBDAV
    RFC3648 Standard WebDAV Ordered Collections Protocol
    RFC3744 Standard WebDAV Access Control Protocol

    Current Meeting Report


    WebDAV IETF 61
    Washington, DC
    2004-11-11

    Agenda
    ------
    - Agenda Bash
    - Process
    - Bugzilla issue tracking:
    http://ietf.webdav.org:8080/bugzilla/
    - Closing issues
    - BIND
    - Redirect
    - QUOTA
    - CalDAV
    - WebDAV events
    (http://www.jabber.org/~stpeter/ietf/draft-hildebrand-webdav-notify -00.html)
    - PATCH
    </agenda>

    <notes>
    (11:07:59) Julian Reschke: Jim: I agree that RFC2518bis should integrate all clarifications that are needed to explain behaviour in presence of multiple bindings. For simplicity, I'd still prefer to leave authorabilty of new bindings for a separate doc.
    (11:08:02) lisa: It did mention a few possibilities, like the possibility for multiple bindings, but that doesn't mean it really "defined" bindings.
    (11:08:22) ***pguenther is playing the role of note taker
    (11:08:39) pguenther: agenda bashing: add a calDAV report
    (11:08:43) pguenther: (at end)
    (11:08:44) Jim Whitehead: Thanks pguenther
    (11:08:59) hardie: We have agreed that CalDAV is the correct orthography, too, so score!
    (11:09:22) lisa: http://ietf.webdav.org:8080/bugzilla
    (11:09:43) pguenther: bugzilla is set up, report problems to Joe
    (11:10:06) pguenther: is the *canonical* repository for issues
    (11:10:22) pguenther: authors cannot close issues, only chairs
    (11:10:40) Jim Whitehead: how many people in the room in DC?
    (11:10:59) MatthewElvey entered the room.
    (11:11:06) pguenther: 8 + ADs + chairs
    (11:11:11) bdesruisseaux entered the room.
    (11:11:14) Jim Whitehead: thx
    (11:11:20) Julian Reschke: bugzilla: I think this needs to cc the mailing list (I know Lisa and Joe have been working on it; but it doesn't seem to work right now)
    (11:11:41) pguenther: right, Joe is still aiming towards that
    (11:11:43) Jim Whitehead: i received a few emails recently. think this integration is working
    (11:11:49) pguenther: sorry, slipped past my typing
    (11:12:11) pguenther: Julian sent in update on Bind
    (11:12:19) pguenther: WGLC on it soon
    (11:12:41) Julian Reschke: (no mails visibile on http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/)
    (11:12:55) Jim Whitehead: what is the plan for resolving open BIND issues and getting to WGLC?
    (11:12:55) pguenther: Lisa, as Julian: no open issues
    (11:13:21) pguenther: Lisa, as Lisa: some items found and put in bugzilla
    (11:13:45) codebear entered the room.
    (11:13:46) Julian Reschke: These issues IMHO are the same we already discussed on the mailing list.
    (11:14:00) Jim Whitehead: so do you think they're open or closed?
    (11:14:09) pguenther: moving on to Redirect: Julian: "Redirect to move forwards after BIND"
    (11:14:22) Julian Reschke: Discussion ended with consensus (as far as I can tell), if that's incorrect we'll need to restart it on the ML.
    (11:14:24) pguenther: Joe doesn't think there are any dependencies, just a matter of work
    (11:14:33) hildjj: Is that correct?
    (11:14:40) Julian Reschke: Yes.
    (11:14:59) Julian Reschke: There is one main issue left for which I'd appreciate feedback, which is...
    (11:15:03) Jim Whitehead: so, will there be one more I-D then WGLC, or are we going directly to WGLC?
    (11:15:07) lisa: I think redirect is closer to WGLC, personally
    (11:15:09) Jim Whitehead: on BIND that is
    (11:15:25) Julian Reschke: ...documented here: http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0180.html
    (11:15:26) lisa: redirect closer to WGLC than Bindings, to be clear (and both of those closer than RFC2518bis)
    (11:15:36) hildjj: Jim: WGLC on this issue, as soon as we get Bugzilla 100%
    (11:15:43) hildjj: issue/version
    (11:15:57) Jim Whitehead: bugzilla 100% means all issues reolved?
    (11:16:07) Julian Reschke: IMHO redirect indeed *has* open issues that need to be resolved before we can go to LC.
    (11:17:00) lisa: Yes Julian, that could be, but redirct has fewer issues and easier to resolve -- that's just my guess, based on the issues I'm aware of.
    (11:17:38) Jim Whitehead: wouldn't surprise me if that's the case -- redirect has fewer impacts on the rest of the DAV data model
    (11:18:00) lisa: that's right
    (11:18:07) Julian Reschke: I personally think that BIND is a litmus test about whether this WG is still functional or not. It has been in almost-last-call state for over 19 months, and it's on top of our prio list. Let's do not move other things in front of it.
    (11:19:14) pguenther: discussion: delete of redirection is the important case, which makes #1 choice preferable
    (11:19:27) pguenther: (or rather, the _really_ important case)
    (11:20:32) pguenther: Julian: Joe agrees with the sentiment of your concern over BIND and reordering the submission of the drafts
    (11:21:59) Julian Reschke: Meta: BIND is stable and has been implemented in various servers, while REDIRECT currently seems to be implemented by one single server (ours). Thus, the WG should keep BIND as #1 prio.
    (11:22:03) Jim Whitehead: i don't have a strong preference over which one is finished first -- obviously want to see both completed
    (11:22:05) pguenther: Ted (Hardie) to submit to bugzilla an issue over DELETE of a redirection not being explicitly described/warned about/pointed out
    (11:23:00) pguenther: moving on to QUOTA
    (11:23:07) pguenther: new draft submitted
    (11:23:15) lisa: Julian, it would be great to get a snapshot of the implementation status of BIND and REDIRECT, on the WG list.
    (11:23:25) pguenther: big change: removed 'authorable' property that was causing the most grief
    (11:23:44) pguenther: handful of nits (Thanks Julian!)
    (11:24:45) pguenther: suggestions to reorganize seem style issues and will be left to author
    (11:24:55) pguenther: WGLC real soon
    (11:25:02) pguenther: CalDAV notes
    (11:25:15) Jim Whitehead: I asked brian when a new draft would be created, haven't received a response. Would be good for him to receive some WG Chair direction on this
    (11:25:32) lisa: Brian just said, in the next week or so after he gets back from DC.
    (11:25:32) hildjj: brian says soon after he gets back.
    (11:25:35) lisa: heh
    (11:25:40) pguenther: calendaring roundtable was held
    (11:25:54) pguenther: added new resources and properties
    (11:26:21) pguenther: fourth draft adds new method 'add calender'
    (11:26:34) lisa: literally "MKCALENDAR"
    (11:27:09) pguenther: reached concensus over changes and are working on searches and some specific calendaring functions
    (11:27:21) lisa: It would be good to get broader feedback on our CalDAV ideas about property promotion...
    (11:27:59) lisa: it adds complexity (since we know we want to support access via iCalendar formatted bodies, anyway) but we're discussing whether the benefits outweigh that.
    (11:28:07) pguenther: property promotion as means to provide better searching including partial retrieval(?)
    (11:28:55) lisa: Yep -- better searching, partial retrieval, partial write. To change the DTSTART of an iCalendar body, the client must upload the whole body again. Unless we reflect the body's DTSTART value as a WebDAV property, in which case you could PROPPATCH only that property.
    (11:28:57) pguenther: discussion on promotion
    (11:29:32) Jim Whitehead: it certainly seems to me that calendar searching will be critical for making CalDAV interesting for Enterprise deployment.
    (11:29:53) lisa: Yes but SEARCH+basicsearch can't even meet the requirements.
    (11:30:19) Jim Whitehead: Doesn't surprise me -- will undoubtedly require a specific CaLDAV search vocabulary
    (11:30:30) pguenther: timezone as example of why a brute force renaming with separator isn't always good
    (11:30:32) lisa: yep -- expanding recurrances, time-range results, etc.
    (11:31:04) pguenther: use reports to do stuff beyond the capabilities of search
    (11:31:16) pguenther: what is being optimized for?
    (11:31:28) pguenther: smarts in server or client?
    (11:31:31) Jim Whitehead: Will also need a richer notion of principal than is provided by ACL spec -- will be tricky to stay away from an entire directory server capability
    (11:31:42) lisa: Why is that, Jim?
    (11:31:44) pguenther: shifted in calsch WG over time
    (11:32:03) pguenther: (where the smarts were expected to be, that is)
    (11:32:04) Jim Whitehead: True, REPORT would be very handy here. Trick is figuring out which REPORTs to support
    (11:32:45) Jim Whitehead: Principals in ACL spec don't have enough metadata (phone number, room number, etc.) -- no problem to add these, just need to have standard property lists
    (11:33:57) pguenther: searching and filtering take place on the server side, with knowledge of recurrence[sic] rules
    (11:34:02) lisa: We may only need one more principal property for CalDAV -- "calendar URL(s)"
    (11:34:13) lisa: the rest of the information can be properties on the calendar resources, I think
    (11:34:14) pguenther: servers _are_ being expected to understand the semantics of the objects
    (11:35:04) Jim Whitehead: For example, Oracle Calendar allows you to associate "organizations" to specific principals, you you can differentiate between the Nguyen in development and the Nguyen in accounting.
    (11:35:14) pguenther: that an assumption of several things, including promotion (but that may be doable with a shim), and recurrence
    (11:35:26) pguenther: the latter being critical to calendaring
    (11:35:49) lisa: Joe just realized he should add the webdav event stuff to the agenda...
    (11:38:08) pguenther: Oracle hoping to have basic IOP by mid January
    (11:38:58) Jim Whitehead: expand "IOP" please?
    (11:39:19) pguenther: sorry, have it in operation
    (11:39:32) pguenther: (short between ears and fingers)
    (11:39:36) Jim Whitehead: OK, what are they hoping to have in operation? CalDAV?
    (11:39:47) Jim Whitehead: Or have we moved on to events?
    (11:39:53) pguenther: yes, with searching
    (11:40:05) pguenther: "what meeting have I not responded to" etc
    (11:40:12) lisa: Joe mentioned the HTTP header registry, which Mark Nottingham is working on
    (11:40:24) lisa: IOP is "interoperability"
    (11:40:57) lisa: Some CalDAV features should interoperate in mid-Jan.
    (11:41:11) Jim Whitehead: Also, shameless plug: there will be an article on WebDAV in the Jan/Feb issue of IEEE Internet Computing. Will focus on the ACL specification
    (11:41:31) Jim Whitehead: How can you have interop when the spec isn't complete yet?
    (11:41:46) bdesruisseaux: The CalDAV protocol adapter of Oracle Calendar should provide support for GET, PUT, DELETE, PROPFIND and REPORTs to allow clients to create, modify, delete events as well as search for them (with reports).
    (11:41:54) Jim Whitehead: Or, put another way, what is the baseline for this?
    (11:42:12) Jim Whitehead: Is the CalDAV adapter going to be publically available?
    (11:42:27) pguenther: taking to list the details of having MKCAL indicate what it is putting up
    (11:42:33) Jim Whitehead: Who is the oracle contact for CalDAV?
    (11:42:56) lisa: Bernard DesRuisseaux
    (11:43:00) lisa: (in this room)
    (11:43:04) bdesruisseaux: We'll make the adapter available outside our firewall for CalDAV cllient initiative to work toward an IOP
    (11:43:08) lisa: (both physical and jabber room)
    (11:43:28) bdesruisseaux: Jim, I am the "dev" contact for CalDAV.
    (11:43:51) Jim Whitehead: Super! Thanks Bernard. We're an oracle calendar shop here at UCSC
    (11:44:16) bdesruisseaux: Good!
    (11:45:32) pguenther: Cyrus: no further immediate needs from CalDAV on WebDAV; if stuff comes up during implementation then it will be taken to the list
    (11:46:21) pguenther: Bernard: in future, stuff like QUOTA may become more important for CalDAV, to prevent DoS attacks in the direct case of QUOTA
    (11:46:30) Julian Reschke: If CalDAV in some way becomes an "official" WebDAV working group item, I'd like to see discussions to actually happen on the mailing list...
    (11:46:48) Jim Whitehead: there are separate mailing lists for caldav
    (11:46:58) Jim Whitehead: seems like it should be a separate WG in any case
    (11:47:07) Julian Reschke: Yes, but there seems to be a lot of out-of-band dicussion :-)
    (11:47:15) Jim Whitehead: :-)
    11:47:29) Jim Whitehead: not clear caldav folks want to be an IETF WG
    (11:47:43) pguenther: for now, the CalDAV is expecting to stay as an individual submission
    (11:47:59) Julian Reschke: nothing wrong with that
    (11:48:30) lisa: There are certainly a lot of out-of-band discussions. Co-authors do that.
    (11:48:35) lisa: :-)
    (11:48:35) pguenther: Ted: HTTP SASL had a bunch of review comments
    (11:48:39) Jim Whitehead: agreed
    (11:49:12) lisa: I believe we're doing a good job of bringing the out-of-band discussions on CalDAV into the spec and publishing it frequently.
    (11:49:17) pguenther: comments are currently unreplied to and is stuck there until that happens, perhaps blocked on SASL WG
    (11:49:17) pguenther: ?
    (11:49:55) pguenther: Waiting on revision from Alexey based on review?
    (11:50:06) pguenther: Lisa: blocked on disagreeing on how HTTP is extensible
    (11:51:35) pguenther: Lisa: a use case for HTTP SASL would help it move forwards, perhaps
    (11:51:42) lisa: Also blocked on understanding why it's needed
    (11:52:02) pguenther: Cyrus/Ted: WebDAV pushing for HTTP SASL may serve
    (11:52:29) lisa: (Scott could probably come up with a proposed model, but he needs to be motivated by understanding "why SASL")
    (11:52:34) lisa: (Scott Lawrence, that is)
    (11:52:41) pguenther: Cyrus: webdav security considerations section, etc
    (11:52:55) pguenther: Moving on to events
    (11:53:23) pguenther: Joe: "being that we're XMPP people, this [events] is XMPP based"
    (11:53:40) Jim Whitehead: Seems like HTTP/DAV is doing fine without SASL. Would need to get buy-in from MSFT and Apache up front, otherwise is DOA. Without this buy-in, seems like it's not worth our time.
    (11:53:57) Jim Whitehead: Is there an events specification out?
    (11:54:06) Jim Whitehead: Or is this in the planning stages?
    (11:54:28) pguenther: http://www.jabber.org/~stpeter/ietf/dradft-saintandre-webdav-notify -00.html
    (11:54:35) Jim Whitehead: thx
    (11:55:01) pguenther: JEP #60 (publish/subscribe protocol on top of Jabber)
    (11:55:10) pguenther: JEP == Jabber Enhancement Proposal
    (11:55:20) pguenther: comes from Jabber Software Foundation
    (11:55:49) pguenther: notify spec says how to use that spec to put on top of it "this resouce was modified", perhaps also "here what was changed"
    (11:55:54) lisa: I've proposed we follow up HTTP SASL questions on the HTTP list and see if we can get broader input there... Jim do you still subscribe to that list? Can you point out the buy-in problem?
    (11:56:09) pguenther: optional new property giving place to go for changes
    (11:56:17) Jim Whitehead: url is actually: http://www.jabber.org/~stpeter/ietf/draft-hildebrand-webdav-notify -00.html
    (11:56:38) Jim Whitehead: I've never been on the SASL list, would be willing to point out buy-in problem.
    (11:56:43) lisa: thanks Jim!
    (11:57:13) pguenther: (this was in revenge, stpeter on joe)
    (11:57:17) lisa: There's not a specific SASL list... so I suggested discussing HTTP SASL on ietf-http-wg@w3.org
    (11:57:34) pguenther: Joe: does this ID deserve a home in WG
    (11:57:35) lisa: I mean, there probably is a SASL list, but our problem is not the SASL part of it.
    (11:57:37) Jim Whitehead: ah, ok. yeah, that list is really quiet
    (11:57:45) pguenther: Ted: isn't this also in atompub?
    (11:57:45) Julian Reschke: yes, there is: http://www.imc.org/ietf-sasl/
    (11:57:53) pguenther: Joe: that's a different draft
    (11:57:57) lisa: Our HTTP/SASL problem is how to extend HTTP in a HTTP-like way, that works with intermediaries, to support SASL -- and why to do so.
    (11:58:03) Jim Whitehead: I can also contact authors directly.
    (11:58:25) pguenther: Cyrus: security? how to do authentication?
    (11:58:27) lisa: I've just asked Alexey Melnikov to try to kick off discussion on mailto:ietf-http-wg@w3.org.
    (11:58:38) pguenther: Joe: if you have SASL it's easy, and XMPP has SASL
    (11:58:38) Jim Whitehead: OK, why do we want SASL? I don't hear lots of calls for replacing current SSL layer, and the CONNECT method isn't getting lots of adoption AFAIK
    (12:00:06) pguenther: Joe: they have a server that has separate "who's allowed to publish" and "who's allowed to subscribe"
    (12:01:38) pguenther: Joe: similarity to XMPP is nice; gives a dual XMPP/WedDAV client ability to use the same creds/stuff to authentice to both
    (12:02:04) pguenther: Cyrus: similar to URLAUTH?
    (12:02:11) pguenther: (from LEMONADE)
    (12:02:34) pguenther: so called "pawn ticket" model: whoever has the token can fetch resource
    (12:02:37) Jim Whitehead: thx -- so the issue gets more important as XMPP gains in adoption, and XMPP/DAV synergies become more useful
    (12:03:08) pguenther: Lisa: old draft of this used by Lycos
    (12:03:15) lisa: Not Lycos, Xythos :-)
    (12:03:41) ***pguenther curses at the phenomes used by English
    (12:03:57) pguenther: Jim: right
    (12:04:51) lisa: Philip are you worried about Phonemes or Pheromones?
    (12:05:30) ***pguenther curses at English in general
    (12:05:36) pguenther: should never made it out of draft
    (12:05:46) pguenther: Moving on to PATCH
    (12:06:17) pguenther: Lisa: unable to register mime-type GDIF due to issues with IPR
    (12:06:35) pguenther: make VCDIF the required form?
    (12:06:56) pguenther: but it can only be used in HTTP/1.1 according to its IPR statement!
    (12:07:08) Julian Reschke left the room (Replaced by new connection).
    (12:07:08) Julian Reschke entered the room.
    (12:07:09) Julian Reschke left the room.
    (12:07:17) Julian Reschke entered the room.
    (12:07:18) pguenther: there is not another diff format out there to use
    (12:07:22) Jim Whitehead: don't understand IPR issue. MIME type registration doesn't involve any exposure of IPR, as I recall
    (12:07:35) pguenther: don't require diff format to be supported?
    (12:07:48) Jim Whitehead: For example, MSFT still has complete control over .doc format, but still has MIME type for it
    (12:08:00) Julian Reschke: I think we'll need at least one simple diff format that all severs and clients will support.
    (12:08:11) pguenther: IANA won't register an application/* type without resolution of IPR issues
    (12:08:34) Julian Reschke: REQUIRING support for a format with unclear IPR is problematic.
    (12:08:48) Jim Whitehead: Agreed
    (12:08:52) lisa: Yes, agreed.
    (12:08:55) lisa: And then... ?
    (12:09:05) Jim Whitehead: Subversion uses vdelta, but that also has a patent on it
    (12:10:09) pguenther: Ted: talk to Jeff Mogul?
    (12:10:17) pguenther: Lisa: yes, he said use VCDIFF
    (12:10:58) pguenther: suggestion to ask Jeff to lean on people to update/extend IPR grant to apply to more uses including WebDAV
    (12:11:00) Julian Reschke: I looked at VCDIFF a few weeks ago and it seems to be way to complicated as a required base format.
    (12:11:03) Jim Whitehead: Seems like we have three choices: (1) explore where a common delta has RAND licensing (or owner is willing to commit to RAND) (2) develop a new diff format that isn't patented (hard, lots of IP in this space) (3) use a really old delta format (like the Unix diff used in SCCS, or possibly even the diffs used in RCS
    (12:11:46) Jim Whitehead: There is also the XML diff format developed by Vitali and Durand, called VTML
    (12:12:01) Julian Reschke: Need to consider different use cases: text patch (as in diff/patch) and binary patch (like when writing back only parts of a binary resource)
    (12:12:37) Julian Reschke: (the latter likely to be useful for clients that map WebDAV to file I/O)
    (12:12:54) Jim Whitehead: VTML URL is http://www.cs.unibo.it/~fabio/bio/papers/1999/SCM99/SCM9.pdf
    (12:13:02) lisa: There's also the XML diff format developed by Adrian Mouat
    (12:13:07) Jim Whitehead: Agreed VTML would be problematic for binary diffs
    (12:13:12) lisa: yup
    (12:13:48) pguenther: Joe: regarding diff comments: "Can of worms; move on for now"
    (12:14:11) pguenther: Lisa: where to put content-type of patch in HTTP?
    (12:14:32) Jim Whitehead: Seems to me we don't really need a compressed diff format. Something that says insert n octets starting at octet y, using encoding z would do the trick
    (12:14:50) Julian Reschke: ...into the content-type header, as defined in RFC2616...
    (12:14:54) hildjj: Jim: that's gdiff, no?
    (12:14:56) pguenther: long history of HTTP Content-Type and "instance-Manipulation" headers
    (12:15:23) Jim Whitehead: Don't know gdiff
    (12:15:39) Julian Reschke: Yep, that's basically gdiff.
    (12:16:04) pguenther: (i.e., can the content-type header be of the underlying object, even when the actual body of the request is really instruction to modify it)
    (12:16:29) Julian Reschke: (http://www.w3.org/TR/NOTE-gdiff-19970901)
    (12:16:34) pguenther: Joe: stuff is clearly still open; PATCH is not a working group item
    (12:16:42) Julian Reschke left the room (Replaced by new connection).
    (12:16:43) Julian Reschke entered the room.
    (12:16:43) Julian Reschke left the room.
    (12:16:46) Jim Whitehead: Just looked at gdiff spec. Would be easy to design something similar, but still markedly different
    (12:16:47) Julian Reschke entered the room.
    (12:16:52) Jim Whitehead: Does gdiff have IPR issues?
    (12:17:04) lisa: Gdiff is not known not to have IPR issues.
    (12:17:24) lisa: I submitted an IANA registration for application/gdiff and it was rejected because IPR issues were not clear.
    (12:17:25) pguenther: Bernard: calendaring change format could be done using diff format, so would be nice there too
    (12:17:35) lisa: Joe
    (12:17:41) lisa: Joe is declaring we're finished...
    (12:17:47) hildjj: anything else before we're done?
    (12:17:48) lisa: unless there are any last-minute issues
    (12:18:11) pguenther: gavel has fallen
    (12:18:18) hildjj: </gavel>
    (12:18:19) bdesruisseaux left the room.
    (12:18:22) Julian Reschke: I'd like us as WG to agree that we concentrate on the topics that are on top of our charter.
    (12:18:37) hildjj: Julian: yes. BIND first.
    (12:19:04) Jim Whitehead: OK
    (12:19:16) hildjj left the room.
    (12:19:16) Julian Reschke: People who do have open issues with the latest draft, *please* post them to the ML for dicussion.
    (12:19:50) Jim Whitehead: OK
    (12:25:41) hardie left the room (Disconnected).
    (12:25:57) codebear left the room.
    (12:26:20) Julian Reschke left the room (Disconnected).
    </notes>

    --
    Joe Hildebrand
    Denver, CO, USA


    Slides

    None received.