[03:51:57] --- reschke has joined
[05:13:31] --- reschke has left: Disconnected
[07:02:07] --- reschke has joined
[07:06:31] --- reschke has left: Replaced by new connection
[07:06:31] --- reschke has joined
[07:06:32] --- reschke has left
[07:08:24] --- reschke has joined
[07:12:24] --- reschke has left: Disconnected
[07:12:28] --- reschke has joined
[07:15:06] --- reschke has left: Replaced by new connection
[07:15:07] --- reschke has joined
[07:15:07] --- reschke has left
[07:19:00] --- reschke has joined
[07:19:11] --- reschke has left
[08:00:33] --- reschke has joined
[10:31:35] --- jreschke has joined
[11:20:21] --- jreschke has left: Replaced by new connection
[11:20:22] --- jreschke has joined
[11:20:22] --- jreschke has left
[11:22:03] --- jreschke has joined
[11:25:21] --- jreschke has left: Replaced by new connection
[11:25:21] --- jreschke has joined
[11:25:21] --- jreschke has left
[11:33:20] --- jreschke has joined
[11:37:29] --- Jim Whitehead has joined
[11:42:14] --- jreschke has left
[11:42:19] --- Julian Reschke has joined
[11:48:53] --- lisa has joined
[11:49:16] <lisa> Hi there!
[11:49:16] --- reschke has left: Lost connection
[11:49:24] <Julian Reschke> Hi
[11:49:37] <lisa> good to see you guys virtually
[11:49:42] <Jim Whitehead> same here
[11:49:58] <Jim Whitehead> has a final agenda been posted?
[11:51:25] <lisa> We've been lame on that...
[11:51:34] <lisa> but of course we're going to discuss bindings and redirect, as suggested
[11:52:14] <lisa> also process (issue tracking) and probably quota
[11:53:31] <Jim Whitehead> ok, sounds good.
[11:53:49] <Jim Whitehead> just wanted to make sure i was on the sam page as everyone else
[11:55:50] <Jim Whitehead> bug #2 for bind (bind and locking behavior) is a tough one
[11:56:14] <Jim Whitehead> one suggestion is to publish bind, and then integrate it into 2518bis
[11:56:29] <Jim Whitehead> the lock issue can then be resolved during the integration
[11:57:41] <Julian Reschke> Jim: as far as I can tell, there's really no issue here that would originate from BIND. RFC2518 already mentions multiple URIs mapped to the same resource, thus it should also say what that means if that resource is locked.
[11:58:17] <Julian Reschke> ...as far as I can tell, it already does that (which if course doesn't mean the language can't be enhanced)
[11:59:20] <Jim Whitehead> I agree that it seems we can duck addressing this issue for now. I just come to the same conclusion from a different direction.
[11:59:30] <lisa> I have had some concrete text suggestions for bug #2. E.g. "Servers MUST support UNLOCK against all bindings to a locked resource, regardless of which binding was used for the LOCK request". Or something similar.
[12:00:07] <lisa> I don't agree we can duck this if binding is going to last call.
[12:00:25] <Jim Whitehead> Seems to me that, by introducing a mechanism for explicitly creating bindings, it's now much more important to address some of the impacts of having multiple bindings to resources.
[12:00:32] <lisa> Unless it's goint to experimental.
[12:00:42] <Jim Whitehead> Don't want the draft to go experimental
[12:00:50] <lisa> Me neither.
[12:00:54] <Jim Whitehead> Lisa's UNLOCK suggestion sounds reasonable
[12:01:16] <Julian Reschke> Lisa: I disagree that this would be enhacement. HTTP methods *always* address resources, and that's what the BIND spec says in it's introduction of that topic. Repeating it for a specific method doesn't make it clearer, because people may start thinking this is a special case (which it isn't=
[12:02:03] <Jim Whitehead> Not sure I agree here. The language in the spec coudl carefully say that this is an implication from the underlying model, but make that implication explicit.
[12:02:23] <lisa> Right Jim, that would be fine.
[12:02:28] <Jim Whitehead> Much of the trouble we got into in 2518 stemmed from us assuming that smart people could correctly extrapolate the model into the myriad edge cases.
[12:02:48] <Jim Whitehead> Turns out smart people are very adept at creating subtly different interpretations which seem consistent
[12:03:29] <Jim Whitehead> Put another way, you were reminding me of Yaron there for a second, Julian :-)
[12:03:53] <Julian Reschke> But then, does this belong into BIND or into RFC2518bis? I would think the latter, as you already can have multiple bindings without having ever invoked BIND.
[12:03:55] <lisa> Particularly if the smart people have different implementations in mind... different motivations to believe different things!
[12:04:01] <Jim Whitehead> :-)
[12:04:12] <lisa> But RFC2518 (or bis) don
[12:04:20] <lisa> ... don't specify interoperable bindings.
[12:04:46] <Jim Whitehead> This is why I think it makes sense to merge these two specs.
[12:04:53] <lisa> heh
[12:05:03] <Jim Whitehead> BIND is essentially affecting the core data model of 2518
[12:05:03] <Julian Reschke> Lisa: What does that mean? Is that intentional, or a bug?
[12:05:05] <lisa> you think that's the right way to finish two large chunks of difficult work???
[12:05:19] <Jim Whitehead> Well, that is a problem :-)
[12:05:39] --- hildjj has joined
[12:05:52] --- hardie has joined
[12:05:58] <lisa> RFC2518 couldn't take on every behind-the-scenes feature that every server could potentially implement, and make them all work the same way. That would have been insane.
[12:06:08] <Jim Whitehead> Hence my suggestion to finish BIND, then start the merge with 2518bis. At least you'll have a stable starting point for the BIND additions. Plus you can decide when to start integrating it.
[12:06:10] --- pguenther has joined
[12:06:11] <hardie> Howdy; we're just getting scribes
[12:06:12] <hildjj> Agenda:
[12:06:14] <hildjj> 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
[12:06:16] <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.
[12:06:18] <lisa> It did mention a few possibilities, like the possibility for multiple bindings, but that doesn't mean it really "defined" bindings.
[12:06:38] * pguenther is playing the role of note taker
[12:06:56] <pguenther> agenda bashing: add a calDAV report
[12:06:59] <pguenther> (at end)
[12:07:00] <Jim Whitehead> Thanks pguenther
[12:07:15] <hardie> We have agreed that CalDAV is the correct orthography, too, so score!
[12:07:39] <lisa> http://ietf.webdav.org:8080/bugzilla
[12:08:00] <pguenther> bugzilla is set up, report problems to Joe
[12:08:22] <pguenther> is the *canonical* repository for issues
[12:08:38] <pguenther> authors cannot close issues, only chairs
[12:08:56] <Jim Whitehead> how many people in the room in DC?
[12:09:15] --- MatthewElvey has joined
[12:09:23] <pguenther> 8 + ADs + chairs
[12:09:27] --- bdesruisseaux has joined
[12:09:31] <Jim Whitehead> thx
[12:09:36] <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)
[12:09:57] <pguenther> right, Joe is still aiming towards that
[12:10:00] <Jim Whitehead> i received a few emails recently. think this integration is working
[12:10:06] <pguenther> sorry, slipped past my typing
[12:10:28] <pguenther> Julian sent in update on Bind
[12:10:35] <pguenther> WGLC on it soon
[12:10:58] <Julian Reschke> (no mails visibile on http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/)
[12:11:10] <Jim Whitehead> what is the plan for resolving open BIND issues and getting to WGLC?
[12:11:12] <pguenther> Lisa, as Julian: no open issues
[12:11:38] <pguenther> Lisa, as Lisa: some items found and put in bugzilla
[12:12:01] --- codebear has joined
[12:12:03] <Julian Reschke> These issues IMHO are the same we already discussed on the mailing list.
[12:12:16] <Jim Whitehead> so do you think they're open or closed?
[12:12:26] <pguenther> moving on to Redirect: Julian: "Redirect to move forwards after BIND"
[12:12:39] <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.
[12:12:40] <pguenther> Joe doesn't think there are any dependencies, just a matter of work
[12:12:49] <hildjj> Is that correct?
[12:12:55] <Julian Reschke> Yes.
[12:13:15] <Julian Reschke> There is one main issue left for which I'd appreciate feedback, which is...
[12:13:20] <Jim Whitehead> so, will there be one more I-D then WGLC, or are we going directly to WGLC?
[12:13:23] <lisa> I think redirect is closer to WGLC, personally
[12:13:25] <Jim Whitehead> on BIND that is
[12:13:41] <Julian Reschke> ...documented here: http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0180.html
[12:13:42] <lisa> redirect closer to WGLC than Bindings, to be clear (and both of those closer than RFC2518bis)
[12:13:52] <hildjj> Jim: WGLC on this issue, as soon as we get Bugzilla 100%
[12:14:00] <hildjj> issue/version
[12:14:13] <Jim Whitehead> bugzilla 100% means all issues reolved?
[12:14:23] <Julian Reschke> IMHO redirect indeed *has* open issues that need to be resolved before we can go to LC.
[12:15:16] <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.
[12:15:54] <Jim Whitehead> wouldn't surprise me if that's the case -- redirect has fewer impacts on the rest of the DAV data model
[12:16:16] <lisa> that's right
[12:16:23] <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.
[12:17:31] <pguenther> discussion: delete of redirection is the important case, which makes #1 choice preferable
[12:17:43] <pguenther> (or rather, the _really_ important case)
[12:18:49] <pguenther> Julian: Joe agrees with the sentiment of your concern over BIND and reordering the submission of the drafts
[12:20:15] <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.
[12:20:19] <Jim Whitehead> i don't have a strong preference over which one is finished first -- obviously want to see both completed
[12:20:22] <pguenther> Ted (Hardie) to submit to bugzilla an issue over DELETE of a redirection not being explicitly described/warned about/pointed out
[12:21:17] <pguenther> moving on to QUOTA
[12:21:24] <pguenther> new draft submitted
[12:21:32] <lisa> Julian, it would be great to get a snapshot of the implementation status of BIND and REDIRECT, on the WG list.
[12:21:41] <pguenther> big change: removed 'authorable' property that was causing the most grief
[12:22:00] <pguenther> handful of nits (Thanks Julian!)
[12:23:02] <pguenther> suggestions to reorganize seem style issues and will be left to author
[12:23:11] <pguenther> WGLC real soon
[12:23:18] <pguenther> CalDAV notes
[12:23:31] <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
[12:23:48] <lisa> Brian just said, in the next week or so after he gets back from DC.
[12:23:48] <hildjj> brian says soon after he gets back.
[12:23:51] <lisa> heh
[12:23:56] <pguenther> calendaring roundtable was held
[12:24:11] <pguenther> added new resources and properties
[12:24:37] <pguenther> fourth draft adds new method 'add calender'
[12:24:51] <lisa> literally "MKCALENDAR"
[12:25:26] <pguenther> reached concensus over changes and are working on searches and some specific calendaring functions
[12:25:37] <lisa> It would be good to get broader feedback on our CalDAV ideas about property promotion...
[12:26:15] <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.
[12:26:23] <pguenther> property promotion as means to provide better searching including partial retrieval(?)
[12:27:12] <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.
[12:27:14] <pguenther> discussion on promotion
[12:27:48] <Jim Whitehead> it certainly seems to me that calendar searching will be critical for making CalDAV interesting for Enterprise deployment.
[12:28:09] <lisa> Yes but SEARCH+basicsearch can't even meet the requirements.
[12:28:36] <Jim Whitehead> Doesn't surprise me -- will undoubtedly require a specific CaLDAV search vocabulary
[12:28:47] <pguenther> timezone as example of why a brute force renaming with separator isn't always good
[12:28:48] <lisa> yep -- expanding recurrances, time-range results, etc.
[12:29:18] <pguenther> use reports to do stuff beyond the capabilities of search
[12:29:33] <pguenther> what is being optimized for?
[12:29:45] <pguenther> smarts in server or client?
[12:29:48] <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
[12:29:59] <lisa> Why is that, Jim?
[12:30:00] <pguenther> shifted in calsch WG over time
[12:30:19] <pguenther> (where the smarts were expected to be, that is)
[12:30:20] <Jim Whitehead> True, REPORT would be very handy here. Trick is figuring out which REPORTs to support
[12:31:02] <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
[12:32:14] <pguenther> searching and filtering take place on the server side, with knowledge of recurrence[sic] rules
[12:32:18] <lisa> We may only need one more principal property for CalDAV -- "calendar URL(s)"
[12:32:29] <lisa> the rest of the information can be properties on the calendar resources, I think
[12:32:30] <pguenther> servers _are_ being expected to understand the semantics of the objects
[12:33:21] <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.
[12:33:31] <pguenther> that an assumption of several things, including promotion (but that may be doable with a shim), and recurrence
[12:33:43] <pguenther> the latter being critical to calendaring
[12:34:05] <lisa> Joe just realized he should add the webdav event stuff to the agenda...
[12:36:24] <pguenther> Oracle hoping to have basic IOP by mid January
[12:37:14] <Jim Whitehead> expand "IOP" please?
[12:37:36] <pguenther> sorry, have it in operation
[12:37:49] <pguenther> (short between ears and fingers)
[12:37:53] <Jim Whitehead> OK, what are they hoping to have in operation? CalDAV?
[12:38:03] <Jim Whitehead> Or have we moved on to events?
[12:38:09] <pguenther> yes, with searching
[12:38:22] <pguenther> "what meeting have I not responded to" etc
[12:38:28] <lisa> Joe mentioned the HTTP header registry, which Mark Nottingham is working on
[12:38:40] <lisa> IOP is "interoperability"
[12:39:14] <lisa> Some CalDAV features should interoperate in mid-Jan.
[12:39:27] <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
[12:39:48] <Jim Whitehead> How can you have interop when the spec isn't complete yet?
[12:40:02] <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).
[12:40:11] <Jim Whitehead> Or, put another way, what is the baseline for this?
[12:40:28] <Jim Whitehead> Is the CalDAV adapter going to be publically available?
[12:40:43] <pguenther> taking to list the details of having MKCAL indicate what it is putting up
[12:40:50] <Jim Whitehead> Who is the oracle contact for CalDAV?
[12:41:12] <lisa> Bernard DesRuisseaux
[12:41:17] <lisa> (in this room)
[12:41:21] <bdesruisseaux> We'll make the adapter available outside our firewall for CalDAV cllient initiative to work toward an IOP
[12:41:24] <lisa> (both physical and jabber room)
[12:41:45] <bdesruisseaux> Jim, I am the "dev" contact for CalDAV.
[12:42:07] <Jim Whitehead> Super! Thanks Bernard. We're an oracle calendar shop here at UCSC
[12:42:33] <bdesruisseaux> Good!
[12:43:48] <pguenther> Cyrus: no further immediate needs from CalDAV on WebDAV; if stuff comes up during implementation then it will be taken to the list
[12:44:38] <pguenther> Bernard: in future, stuff like QUOTA may become more important for CalDAV, to prevent DoS attacks in the direct case of QUOTA
[12:44:46] <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...
[12:45:05] <Jim Whitehead> there are separate mailing lists for caldav
[12:45:14] <Jim Whitehead> seems like it should be a separate WG in any case
[12:45:24] <Julian Reschke> Yes, but there seems to be a lot of out-of-band dicussion :-)
[12:45:32] <Jim Whitehead> :-)
[12:45:45] <Jim Whitehead> not clear caldav folks want to be an IETF WG
[12:46:00] <pguenther> for now, the CalDAV is expecting to stay as an individual submission
[12:46:16] <Julian Reschke> nothing wrong with that
[12:46:46] <lisa> There are certainly a lot of out-of-band discussions. Co-authors do that.
[12:46:51] <lisa> :)
[12:46:51] <pguenther> Ted: HTTP SASL had a bunch of review comments
[12:46:55] <Jim Whitehead> agreed
[12:47:28] <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.
[12:47:33] <pguenther> comments are currently unreplied to and is stuck there until that happens, perhaps blocked on SASL WG
[12:47:34] <pguenther> ?
[12:48:11] <pguenther> Waiting on revision from Alexey based on review?
[12:48:22] <pguenther> Lisa: blocked on disagreeing on how HTTP is extensible
[12:49:51] <pguenther> Lisa: a use case for HTTP SASL would help it move forwards, perhaps
[12:49:59] <lisa> Also blocked on understanding why it's needed
[12:50:19] <pguenther> Cyrus/Ted: WebDAV pushing for HTTP SASL may serve
[12:50:46] <lisa> (Scott could probably come up with a proposed model, but he needs to be motivated by understanding "why SASL")
[12:50:51] <lisa> (Scott Lawrence, that is)
[12:50:57] <pguenther> Cyrus: webdav security considerations section, etc
[12:51:11] <pguenther> Moving on to events
[12:51:40] <pguenther> Joe: "being that we're XMPP people, this [events] is XMPP based"
[12:51:56] <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.
[12:52:14] <Jim Whitehead> Is there an events specification out?
[12:52:23] <Jim Whitehead> Or is this in the planning stages?
[12:52:44] <pguenther> http://www.jabber.org/~stpeter/ietf/dradft-saintandre-webdav-notify-00.html
[12:52:52] <Jim Whitehead> thx
[12:53:18] <pguenther> JEP #60 (publish/subscribe protocol on top of Jabber)
[12:53:26] <pguenther> JEP == Jabber Enhancement Proposal
[12:53:37] <pguenther> comes from Jabber Software Foundation
[12:54:05] <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"
[12:54:11] <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?
[12:54:26] <pguenther> optional new property giving place to go for changes
[12:54:34] <Jim Whitehead> url is actually: http://www.jabber.org/~stpeter/ietf/draft-hildebrand-webdav-notify-00.html
[12:54:55] <Jim Whitehead> I've never been on the SASL list, would be willing to point out buy-in problem.
[12:55:00] <lisa> thanks Jim!
[12:55:30] <pguenther> (this was in revenge, stpeter on joe)
[12:55:33] <lisa> There's not a specific SASL list... so I suggested discussing HTTP SASL on ietf-http-wg@w3.org
[12:55:50] <pguenther> Joe: does this ID deserve a home in WG
[12:55:52] <lisa> I mean, there probably is a SASL list, but our problem is not the SASL part of it.
[12:55:54] <Jim Whitehead> ah, ok. yeah, that list is really quiet
[12:56:01] <pguenther> Ted: isn't this also in atompub?
[12:56:02] <Julian Reschke> yes, there is: http://www.imc.org/ietf-sasl/
[12:56:10] <pguenther> Joe: that's a different draft
[12:56:14] <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.
[12:56:19] <Jim Whitehead> I can also contact authors directly.
[12:56:42] <pguenther> Cyrus: security? how to do authentication?
[12:56:43] <lisa> I've just asked Alexey Melnikov to try to kick off discussion on mailto:ietf-http-wg@w3.org.
[12:56:54] <pguenther> Joe: if you have SASL it's easy, and XMPP has SASL
[12:56:55] <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:58:23] <pguenther> Joe: they have a server that has separate "who's allowed to publish" and "who's allowed to subscribe"
[12:59:55] <pguenther> Joe: similarity to XMPP is nice; gives a dual XMPP/WedDAV client ability to use the same creds/stuff to authentice to both
[13:00:20] <pguenther> Cyrus: similar to URLAUTH?
[13:00:28] <pguenther> (from LEMONADE)
[13:00:51] <pguenther> so called "pawn ticket" model: whoever has the token can fetch resource
[13:00:54] <Jim Whitehead> thx -- so the issue gets more important as XMPP gains in adoption, and XMPP/DAV synergies become more useful
[13:01:25] <pguenther> Lisa: old draft of this used by Lycos
[13:01:31] <lisa> Not Lycos, Xythos :)
[13:01:57] * pguenther curses at the phenomes used by English
[13:02:14] <pguenther> Jim: right
[13:03:07] <lisa> Philip are you worried about Phonemes or Pheromones?
[13:03:47] * pguenther curses at English in general
[13:03:53] <pguenther> should never made it out of draft
[13:04:03] <pguenther> Moving on to PATCH
[13:04:34] <pguenther> Lisa: unable to register mime-type GDIF due to issues with IPR
[13:04:52] <pguenther> make VCDIF the required form?
[13:05:12] <pguenther> but it can only be used in HTTP/1.1 according to its IPR statement!
[13:05:25] --- Julian Reschke has left: Replaced by new connection
[13:05:25] --- Julian Reschke has joined
[13:05:25] --- Julian Reschke has left
[13:05:34] --- Julian Reschke has joined
[13:05:35] <pguenther> there is not another diff format out there to use
[13:05:39] <Jim Whitehead> don't understand IPR issue. MIME type registration doesn't involve any exposure of IPR, as I recall
[13:05:52] <pguenther> don't require diff format to be supported?
[13:06:05] <Jim Whitehead> For example, MSFT still has complete control over .doc format, but still has MIME type for it
[13:06:16] <Julian Reschke> I think we'll need at least one simple diff format that all severs and clients will support.
[13:06:27] <pguenther> IANA won't register an application/* type without resolution of IPR issues
[13:06:49] <Julian Reschke> REQUIRING support for a format with unclear IPR is problematic.
[13:07:04] <Jim Whitehead> Agreed
[13:07:09] <lisa> Yes, agreed.
[13:07:11] <lisa> And then... ?
[13:07:21] <Jim Whitehead> Subversion uses vdelta, but that also has a patent on it
[13:08:25] <pguenther> Ted: talk to Jeff Mogul?
[13:08:33] <pguenther> Lisa: yes, he said use VCDIFF
[13:09:14] <pguenther> suggestion to ask Jeff to lean on people to update/extend IPR grant to apply to more uses including WebDAV
[13:09:17] <Julian Reschke> I looked at VCDIFF a few weeks ago and it seems to be way to complicated as a required base format.
[13:09:20] <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
[13:10:03] <Jim Whitehead> There is also the XML diff format developed by Vitali and Durand, called VTML
[13:10:18] <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)
[13:10:54] <Julian Reschke> (the latter likely to be useful for clients that map WebDAV to file I/O)
[13:11:11] <Jim Whitehead> VTML URL is http://www.cs.unibo.it/~fabio/bio/papers/1999/SCM99/SCM9.pdf
[13:11:19] <lisa> There's also the XML diff format developed by Adrian Mouat
[13:11:23] <Jim Whitehead> Agreed VTML would be problematic for binary diffs
[13:11:28] <lisa> yup
[13:12:05] <pguenther> Joe: regarding diff comments: "Can of worms; move on for now"
[13:12:28] <pguenther> Lisa: where to put content-type of patch in HTTP?
[13:12:49] <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
[13:13:07] <Julian Reschke> ...into the content-type header, as defined in RFC2616...
[13:13:10] <hildjj> Jim: that's gdiff, no?
[13:13:12] <pguenther> long history of HTTP Content-Type and "instance-Manipulation" headers
[13:13:39] <Jim Whitehead> Don't know gdiff
[13:13:55] <Julian Reschke> Yep, that's basically gdiff.
[13:14:21] <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)
[13:14:45] <Julian Reschke> (http://www.w3.org/TR/NOTE-gdiff-19970901)
[13:14:51] <pguenther> Joe: stuff is clearly still open; PATCH is not a working group item
[13:14:59] --- Julian Reschke has left: Replaced by new connection
[13:14:59] --- Julian Reschke has joined
[13:14:59] --- Julian Reschke has left
[13:15:02] <Jim Whitehead> Just looked at gdiff spec. Would be easy to design something similar, but still markedly different
[13:15:04] --- Julian Reschke has joined
[13:15:09] <Jim Whitehead> Does gdiff have IPR issues?
[13:15:21] <lisa> Gdiff is not known not to have IPR issues.
[13:15:40] <lisa> I submitted an IANA registration for application/gdiff and it was rejected because IPR issues were not clear.
[13:15:42] <pguenther> Bernard: calendaring change format could be done using diff format, so would be nice there too
[13:15:52] <lisa> Joe
[13:15:58] <lisa> Joe is declaring we're finished...
[13:16:03] <hildjj> anything else before we're done?
[13:16:05] <lisa> unless there are any last-minute issues
[13:16:27] <pguenther> gavel has fallen
[13:16:34] <hildjj> </gavel>
[13:16:35] --- bdesruisseaux has left
[13:16:39] <Julian Reschke> I'd like us as WG to agree that we concentrate on the topics that are on top of our charter.
[13:16:53] <hildjj> Julian: yes. BIND first.
[13:17:21] <Jim Whitehead> OK
[13:17:32] --- hildjj has left
[13:17:33] <Julian Reschke> People who do have open issues with the latest draft, *please* post them to the ML for dicussion.
[13:18:07] <Jim Whitehead> OK
[13:23:57] --- hardie has left: Disconnected
[13:24:14] --- codebear has left
[13:24:37] --- Julian Reschke has left: Disconnected
[13:26:04] --- pguenther has left
[13:28:33] --- lisa has left: Disconnected
[13:28:53] --- Jim Whitehead has left
[13:40:34] --- MatthewElvey has left: Disconnected
[13:48:34] --- rlbob has joined
[13:52:58] --- lisa has joined
[14:12:58] --- rlbob has left: Disconnected
[14:20:38] --- lisa has left