Re: Combined set of issues around lock tokens, examples, schemes

Jim Whitehead wrote:
>> More changes that I think do not represent WG consensus:
>>
>> 1: <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis- 
>> latest.html#rfc.section.9.5.3.p.4>:
>>
>> -- 
>> The Not production is particularly useful with the "<DAV:no-lock>"  
>> state token. The clause "Not <DAV:no-lock>" MUST evaluate to true.  
>> Thus, any "OR" statement containing the clause "Not <DAV:no-lock>"  
>> MUST also evaluate to true.
>> -- 
> 
> 
> This sounds right to me.
> 
>>
>> This now says MUST instead of "must". I'm not sure why RFC2119  
>> terminology is invoked here. URIs in the DAV: namespace by  definition 
>> never represent a lock token, because they can only be  assigned by 
>> the IETF or this WG. So the statement applies to *all*  URIs that use 
>> the DAV: URI scheme, "DAV:no-lock" is just one example.
>>
>> If you really feel that this needs to be stated somewhere, please  
>> don't make it sound as if "DAV:no-lock" is different from -- for  
>> instance -- "DAV:lock".
> 
> 
> I know there was an issue with organizations adding things to the  DAV: 
> namespace without using the IETF process. However, this section  doesn't 
> seem like the right place to address this issue.

OK, but hat doesn't change the argument. No URI in the DAV: scheme ever 
identifies a valid lock token, by definition. Saying "MUST" and only 
stating "DAV:no-lock" *will* cause implementors to add special code for 
this one string.

>> 2: <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis- 
>> latest-from-07.diff.html#diff-30>:
>>
>> Why was the registration for "opaquelocktoken" removed from the  IANA 
>> considerations? Thinking of it, why was the definition for the  "DAV" 
>> URI scheme removed as well?????
>>
> 
> Based on Ted Hardie's email of today, it sounds like these will  
> continue to be registered, whether in the IANA considerations section  
> or no. That said, it would be useful to have a brief sentence to the  
> effect of, "the URI registrations for opaquelocktoken and DAV URI  
> schemes made in RFC 2518 should still be considered active."

Jim, does that mean that we leave out all stuff that doesn't need 
changes? People would still be able to look it up in RFC2518, after all. 
Me confused.

Best regards, Julian

Received on Saturday, 29 October 2005 07:43:45 UTC