headers
Julian Reschke | 1 Nov 2004 20:47
Picon
Picon

comments on draft-ietf-webdav-quota-04.txt, was: Fwd: I-D ACTION:draft-ietf-webdav-quota-04.txt


Brian,

thanks for the new draft; getting rid of the authorability part greatly 
simplifies the spec.

Below are my updated comments.

Best regards, Julian

Issues with draft-ietf-webdav-quota-04.txt

Content

01-C01 Organization
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0425.html>
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0438.html>

I think the draft could greatly benefit by a more clean separation of 
(a) terminology, (b) protocol (property/error code) definition and (c) 
examples.

Proposal for a outline:

1 Introduction/Notation/Terminology
2 Additional live properties
3 Modification to behaviour of existing methods (error marshalling)
4...n Other standard RFC section
A (Appendix) Examples of how servers may implement quota
(Continue reading)

Permalink | Reply | 14 comments |
headers
Julian Reschke | 5 Nov 2004 20:44
Picon
Picon

Re: WebDAV at IETF 61


Hi,

for those who didn't notice (I haven't seen an announcement here): the 
meeting is scheduled for November 11, 1pm (2004-11-11T18:00Z).  For 
instructions how to particate using text conferencing, check 
<http://www.xmpp.org/ietf-chat.html>.

I'll not be able to attend the meeting, but I'll try to be on-line (see 
above). Here's a status summary for the drafts I'm currently editing:

1) BIND

Basically, no change for a long time, see summary in my previous status 
summary: 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JulSep/0071.html>. 
The authors are waiting for the draft to be last-called, and as far as I 
am concerned, there are no open issues wth it.

The current draft (with minor editorial changes) is 
<http://www.webdav.org/bind/draft-ietf-webdav-bind-07.html>, the issues 
list can be found at 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html>.

2) REDIRECT

There are only a few issues left (see latest message 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0027.html>, 
  current draft 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-10.html>,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 6 Nov 2004 16:40
Picon
Picon

BIND: references to RFC2396


Hi,

now that RFC2396bis has been accepted for publication, I have changed 
the references inside the document accordingly (see 
<http://www.webdav.org/bind/draft-ietf-webdav-bind-latest.html#rfc.issue.rfc2396bis>).

Note: for BIND this was a very simple change; other specs may need more 
work as lots of grammar production and also terminlogy changed in 
comparison to RFC2396 (for instance, the term "relative URI reference" 
isn't used anymore).

Best regards, Julian

--

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Permalink | Reply | 0 comments |
headers
Jim Whitehead | 12 Nov 2004 02:22
Favicon
Gravatar

Comment on UNBIND language in BIND specification


I'm reading through the BIND specification, and the description of the
REBIND method's operands is a bit unclear to me. I'm assuming the intent is
similar to BIND and UNBIND, each of which clearly state in the first
sentence what role the Request-URI, segment, and href fields play. In my
reading I just jumped right into the spec. at this method (typical reference
reading pattern), and hence I didn't initially see the similarity with the
BIND and UNBIND method operands.

- Jim
Permalink | Reply | 5 comments |
headers
Jim Luther | 12 Nov 2004 02:42
Picon
Favicon

Property size limitations


PROPPATCH can fail with 507 (Insufficient Storage). Does anyone know 
what the maximum size for properties is on common WebDAV server 
implementations?

Thanks,

Jim
Permalink | Reply | 0 comments |
headers
Julian Reschke | 12 Nov 2004 15:33
Picon
Picon

Re: Comment on UNBIND language in BIND specification


Jim Whitehead wrote:
> I'm reading through the BIND specification, and the description of the
> REBIND method's operands is a bit unclear to me. I'm assuming the intent is
> similar to BIND and UNBIND, each of which clearly state in the first
> sentence what role the Request-URI, segment, and href fields play. In my
> reading I just jumped right into the spec. at this method (typical reference
> reading pattern), and hence I didn't initially see the similarity with the
> BIND and UNBIND method operands.

Agreed.

Would replacing

"The REBIND method removes a binding to a resource from one collection, 
and adds a binding to that resource into another collection. It is 
effectively an atomic form of a MOVE request."

by

"The REBIND method removes a binding to a resource from the collection 
identified by the Request-URI, and adds a binding to that resource into 
another collection. It is effectively an atomic form of a MOVE request."

be sufficient?

Best regards, Julian

--

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
(Continue reading)

Permalink | Reply | 4 comments |
headers
Julian Reschke | 12 Nov 2004 17:21
Picon
Picon

Re: Comment on UNBIND language in BIND specification


Julian Reschke wrote:
> 
> Jim Whitehead wrote:
> 
>> I'm reading through the BIND specification, and the description of the
>> REBIND method's operands is a bit unclear to me. I'm assuming the 
>> intent is
>> similar to BIND and UNBIND, each of which clearly state in the first
>> sentence what role the Request-URI, segment, and href fields play. In my
>> reading I just jumped right into the spec. at this method (typical 
>> reference
>> reading pattern), and hence I didn't initially see the similarity with 
>> the
>> BIND and UNBIND method operands.
> 
> 
> Agreed.
> 
> Would replacing
> 
> "The REBIND method removes a binding to a resource from one collection, 
> and adds a binding to that resource into another collection. It is 
> effectively an atomic form of a MOVE request."
> 
> by
> 
> "The REBIND method removes a binding to a resource from the collection 
> identified by the Request-URI, and adds a binding to that resource into 
> another collection. It is effectively an atomic form of a MOVE request."
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jim Whitehead | 12 Nov 2004 19:19
Favicon
Gravatar

RE: Comment on UNBIND language in BIND specification


Julian,

> I expanded the replacement further to:
> 
>     The REBIND method removes a binding to a resource from the collection
>     identified by the Request-URI, and adds a binding to that resource
>     into another collection.  The request body specifies the segment to
>     be removed and the new binding to be created (href element).  It is
>     effectively an atomic form of a MOVE request.

I like this language, though I suggest the following tweak for the second
sentence to fix the fact that we're not removing a segment, we're removing a
binding:

The request body specifies the binding to be removed (segment) and the new
binding to be created (href).

- Jim
Permalink | Reply | 2 comments |
headers
Julian Reschke | 12 Nov 2004 20:08
Picon
Picon

Re: Comment on UNBIND language in BIND specification


Jim Whitehead wrote:
> Julian,
> 
> 
>>I expanded the replacement further to:
>>
>>    The REBIND method removes a binding to a resource from the collection
>>    identified by the Request-URI, and adds a binding to that resource
>>    into another collection.  The request body specifies the segment to
>>    be removed and the new binding to be created (href element).  It is
>>    effectively an atomic form of a MOVE request.
> 
> 
> I like this language, though I suggest the following tweak for the second
> sentence to fix the fact that we're not removing a segment, we're removing a
> binding:
> 
> The request body specifies the binding to be removed (segment) and the new
> binding to be created (href).

Good catch. I'll make that change.

Best regards, Julian

--

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Permalink | Reply | 1 comment |
headers
Julian Reschke | 13 Nov 2004 12:27
Picon
Picon

Re: I-D ACTION:draft-ietf-webdav-bind-07.txt


Lisa Dusseault wrote:
> 
> 
> On Oct 15, 2004, at 11:37 AM, Julian Reschke wrote:
> 
>>
>>
>> I'm not sure why you don't want to discuss those though. IETF working 
>> groups by definition do their work on their respective mailing lists; 
>> whether or not a supporting bug tracking system (which will have to 
>> send change notifications to the mailing list anyway) is in place 
>> should not be relevant (although this probably will be helpful).
>>
> I am quite willing to discuss these on the list, what I said was that I 
> wasn't interested in discussing them on the list now (not until Joe's 
> ready to monitor the issue discussions and track issues and declare 
> consensus.)

OK, as far as I can tell (mentioned during the WG meeting [0]), the 
Issues Tracker has been set up (although I haven't seen it CCing the 
mailing list like it should).  So this should mean that we can get back 
to do actual work on the spec.

IMHO the right way to proceed is to review the author's issues list 
([1]) and to verify that issue resolutions match the WG consensus back 
when the issue was discussed.  If the originator of an issue is *not* 
satisfied, I'd expect him/her to continue the discussion here on the 
mailing list.  Raising the issue once and then not replying to answers 
indicates (to me) that the answer/resolution was OK, though.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane