Re: Proposal for WebDAV WG meeting agenda for 62nd IETF - Minneapolis, MN, USA

There is a meeting, but I didn't get any suggestions for the agenda  
until now.  Thanks for the input and broadcasting this info.

Lisa

On Mar 7, 2005, at 11:51 AM, Julian Reschke wrote:

>
> Hi,
>
> unfortunately, there's still no feedback on whether there actually is  
> a WG meeting in Minneapolis (no announcement, no agenda).
>
> In case it *does* take place, here are the details:
>
> Time: 2005-03-09T15:00:00Z (9am local time) (ics:  
> <http://greenbytes.de/tech/webdav/webdav.ics>
>
> Room: Duluth
>
> Text confererencing instructions: <http://www.xmpp.org/ietf-chat.html>
>
> Audio cast: <http://videolab.uoregon.edu/events/ietf/ietf626.m3u> (see  
> <http://videolab.uoregon.edu/events/ietf/> for technical information).
>
> Below is a list of topics I'd like to see discussed.
>
> Best regards, Julian
>
>
> -- snip --
>
>
>
> Proposal for a WebDAV WG meeting agenda
>
> I think we need to have a meta-discussion on how the working group  
> currently operates; and also discuss current technical issues with  
> drafts.
>
>
> A. Meta
>
> The charter (<http://www.ietf.org/html.charters/webdav-charter.html>)  
> has been revised just a year ago and we already have missed all  
> milestones.
>
> A1. What are the reasons for the apparent inability to ship specs in  
> time?
>
> A2. Do we need to re-adjust the charter (again)?
>
> A3. Is the Working Group still able to fulfill it's goals, or would it  
> make more sense to let the individual spec authors proceed with their  
> work outside an IETF working group (for instance, the revision to  
> RFC2396 was done that way)?
>
>
> B. Technical Issues
>
> B1. BIND
>
> As far as I can tell, WG last-call has finished, and the issues that  
> were raised after end of last-call do not qualify as blockers as they  
> have been answered with no feedback and have no votes on them. Thus,  
> draft 11 should have been sent to the IETF for publication (see  
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/ 
> 0278.html>).
>
> B2. QUOTA
>
> This one has been drastically simplified and thus only needs very  
> minor edits for WG last-call. If the WG is really interested in  
> getting it out of the door, the author(s) and the active mailing list  
> members should cooperate to get the remaining issues resolved (last  
> issues list:  
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/ 
> 0194.html>).
>
> B3. REDIRECT
>
> As far as I can tell, we (greenbytes) are the only ones actively  
> working on this (both spec and implementation). I think the spec is  
> very close to be finished; but I would prefer to have it fully  
> implemented before proceeding.
>
> B4. RFC2518bis vs separate locking document
>
> The latest draft of RFC2518bis has expired and I haven't seen any  
> activity on it for a long time. A statement from the authors would be  
> appreciated.
>
> Over a year ago I suggested an alternative approach: split RFC2518  
> base and locking protocol, then work on RFC2518bis (RFC2518 minus  
> locking) and a separate locking document in parallel. RFC2518bis could  
> probably be published as Draft Standard, while LOCKING (which has most  
> of the changes) would need to re-start as Proposed Standard. The  
> proposed LOCKING document is almost done, and could be finished with  
> the backing of the WG in just a few weeks (see latest edits at  
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking- 
> latest.html>). I hereby ask the Working Group chairs to either fix the  
> apparent process issues with RFC2518bis, or to go with the proposal  
> made by me.
>
> B5. PROPERTY DATATYPES
>
> The latest draft
> (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-property- 
> datatypes-08.html>) has been submitted in September 2004 to the RFC  
> Editor for publication as an Experimental RFC (see status at
> <http://www.rfc-editor.org/queue.html#reschke-webdav-property- 
> datatypes>).
>
> In the meantime I have learned that it's unlikely to be processed  
> (which doesn't mean published) any time soon; this part of the RFC  
> Editor's publication queue more or less is stalled. Alternatives to  
> waiting (at least another year if things progress the same way as in  
> the last months) are (a) making this a WG work item or (b) submitting  
> it to our Area Director. As this draft describes both the consensus of  
> the WG (as far as I can tell) *and* running and deployed code, (b)  
> seems to be very attractive.
>
>
>
>
>

Received on Tuesday, 8 March 2005 02:14:20 UTC