Re: PATCH proposal

Lisa Dusseault wrote:

> I  believe that it *is* going through a mailing list last-call, as much 
> as an independent submission that is not being adopted by a WG ever goes 
> through a WG mailing list last call. It will also go through IETF 
> mailing list call, as a matter of course.

OK, to clarify: what I expect is a statement like "I'm last-calling this 
draft", posted to http mailing list (<<ietf-http-wg@w3.org>), and only 
then the draft that was last-called (or an updated version) being 
submitted to the IETF for publication (the IETF will then do another 
last-call of course).

> Anyway, as far as making changes after submission, since you suggested a 
> reasonable reorg (a new section on interdependencies with other 
> standards), and since I realized that security considerations were 
> missing, the changes based on your comments are now definitely going to 
> require another draft version. I will be publishing draft -05 shortly if 
> I don't get any more comments, now that PATCH has gone through several 
> drafts without any material changes, perhaps -05 will be the draft to be 
> submitted for RFC.

Sounds good.

>> I appreciate if this is clarified; maybe the paragraph needs to be 
>> expanded and/or moved into a separate section (interdependencies with 
>> other specs)?
> 
> 
> I can do that; thanks for the specific suggestion.

Great. I think the (my) confusion was caused by the text appearing in 
the midst of the PATCH method description. Moving it somewhere else will 
help.

>>>> C-03-08, Section 3.2.2
>>>>
>>>> 2) Make this optional for servers that do not care about WebDAV.
>>>
>>> This section has nothing to do with support for WebDAV on either 
>>> side.   HTTP clients supporting PATCH can use error messages in the 
>>> body just  as well as WebDAV clients do.  I do not agree with making 
>>> it optional  at any rate; it's easy for the server, optional for the 
>>> client, and  promotes interoperability.
>>
>>
>> As developer of WebDAV servers, I don't have any problem with that. 
>> However, I feel that there are people out there who'd prefer to have 
>> zero dependencies on WebDAV or related specs; and IMHO we should 
>> respect that.
> 
> 
> IMHO we are respecting that.  This doesn't require a server to implement 
> any WebDAV features or even read the DeltaV spec.

No, the server doesn't need to read the DeltaV spec :-) But, as a matter 
of fact, the implementor needs to read & understand at least the section 
of RFC3253 that defines the error marshalling.

I'm not objecting to this, but I feel that others on this mailing list 
would prefer to have this as optional feature. Feedback appreciated.

>>>> 3) Put the condition names into a different namespace, unless the  
>>>> WebDAV WG
>>>> agrees to adopt these names (for instance use, urn:ietf:rfc:xxxx).
>>>
>>> The WebDAV WG has many chances to review this draft and object to the 
>>>  use of the DAV: namespace.  I interpret silence as consent to adopt  
>>> these names.
>>
>>
>> With all due respect: I'm a member of the WebDAV WG and I have 
>> objected to this. This is *not* 'silence'! If you want to use the DAV: 
>> namespace, send an *explicit* request to the mailing list and try to 
>> get consensur in favor of it.
> 
> 
> I misunderstood.  Do you think it is wrong to use the "DAV:" namespace? 

Yes.

>  If you think it is wrong, please say so.  I thought you said that the 
> WG should agree to the use of the namespace, which is what we're doing. 

I said (or meant to say) that the spec shouldn't use the DAV: namespaces 
unless there's a clear consensus on the WebDAV WG mailing list in favor 
of it. As far as I can tell, there isn't, so it shouldn't use it.

>  This is an explicit discussion on the mailing list about whether that's 
> OK.
> 
> I personally think it's OK but will replace the namespace if I get a 
> bunch of objections.

As a matter of fact, you should replace it unless you get a clear 
consensus *in favor* of using it.

>>>> 3) Stick to RFC3253's terminology (the names identify conditions, 
>>>> not  errors, thus
>>>>
>>>> s/DAV:delta-format-unsupported/p:delta-format-supported/
>>>> s/DAV:delta-format-forbidden-on-resource/p:delta-format-allowed-on- 
>>>> resource/
>>>> s/DAV:delta-format-badly-formatted/p:delta-documented-well-formatted/
>>>> s/DAV:delta-empty-resource/p:delta-format-applies-to-empty/
>>>> S/DAV:patch-result-invalid/p:patch-result-valid/
>>>
>>> As you know from this and other specs, I am sticking to the HTTP  
>>> approach, describing the error rather than the condition that would 
>>> be  a lack of an error.  Describing the error is far more natural (in 
>>> many  protocols, not just HTTP) and promotes readability of the spec 
>>> and of  the error responses when they're encountered by programmers 
>>> or  analysts.
>>
>>
>> Once you pick an existing protocol element - stick with it's 
>> semantics. I'm not saying that identifying errors instead of 
>> conditions by itself is bad; but it's inconsistent with what RFC3253 
>> (from which you borrow) defines. If you don't like the semantics of a 
>> protocol element, by all means do NOT reuse it with silently changed 
>> semantics.
> 
> 
> They're just string constants so there is no silently changed 
> semantics.  The interpretation is different but they're machine-readable 
> codes.  At this point, I think we disagree on a naming convention and 
> can agree to disagree on the tradeoffs between consistency and 
> readability.  I didn't think it was so important that I was willing to 
> hold up DeltaV so that DeltaV would do it my way.

Well, RFC3253 *is* a standard; and it seems that back when that decision 
was made, there was a certain amount of consensus for it, otherwise it 
wouldn't look like it is today. What you're doing here really looks a 
bit like revisionism; please accept and respect other people's work and 
do not re-use in a slightly different way.

As you say, these are just string constants, so what's the benefit of 
being inconsistent with the base spec?

>>>> C-03-09, Section 3.3
>>>>
>>>> "OPTIONS * is not used to advertise support for PATCH because the
>>>> delta formats supported are likely to change from one resource to
>>>> another.  A server MAY include the Accept-Patch header in response to
>>>> OPTIONS *, and its value MAY be the union of known supported delta
>>>> formats."
>>>>
>>>> I think that if this paragraph is removed, the spec still says the same
>>>> thing. It doesn't add anything that doesn't already follow from  
>>>> RFC2616.
>>>>
>>> What "follows from RFC2616" differs for many people.  I added this
>>
>>
>> (shouldn't)
> 
> 
> Huh? Are you saying that RFC2616 implications shouldn't differ for many 
> people?  Does that mean:
>    "RFC2616 is so clear that everybody reading it draws the same 
> conclusions even about how extensions to RFC2616 might work"
> or
>    "RFC2616 should be (but isn't) so clear that everybody reading it 
> draws the same conclusions even about how extensions to RFC2616 might work"

The latter. But anyway, it's not the job of PATCH (or any other 
HTTP-related spec) to clarify RFC2616. That's the job of RFC2616bis (for 
which there is an issues list).

> Or something else?  And what does this imply for PATCH?
> 
>>
>>> paragraph because there was lots of confusion and discussion about 
>>> the  appropriateness of OPTIONS *.  A reader of this spec shouldn't 
>>> need to  read the entire mailing lists to understand how OPTIONS * 
>>> might work in  this situation.  Besides, this helps servers that do 
>>> support OPTIONS *  do so in a consistent manner -- showing the union 
>>> of supported delta  formats, rather than some other value in the 
>>> Accept-Patch header.
>>
>>
>> I still think this is a mistake. Following your line of argument, any 
>> HTTP-related spec would need to explain how it doesn't affect the 
>> semantics of "OPTIONS *".
> 
> 
> Yup.  That is, in fact, my line of argument -- any HTTP-related spec 
> that extends the OPTIONS response needs to explain how that extension 
> works for OPTIONS *.

Well, we disagree.

 > ...

Best regards, Julian

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

Received on Tuesday, 24 August 2004 17:43:36 UTC