- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 24 Aug 2004 19:42:58 +0200
- To: Lisa Dusseault <lisa@osafoundation.org>
- CC: HTTP working group <ietf-http-wg@w3.org>, Webdav WG <w3c-dist-auth@w3c.org>
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