W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2004

Re: Fwd: I-D ACTION:draft-dusseault-http-patch-05.txt

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 02 Sep 2004 20:26:57 +0200
Message-ID: <413765F1.7080802@gmx.de>
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:

> This is the latest version of PATCH. Compared to the -04 draft:
> - Moved sections for interoperability with RFC3744 (ACL) and RFC3230 
> (Instance digests) to new section
> - now has Security Considerations and IANA Considerations sections
> - removed references in abstract
> - No longer uses "DAV:" namespace for any new syntax, instead defines 
> own namespace & registers with IANA
> 
> Once again, if I don't get feedback that requires changes beyond typos, 
> I intend to submit this to standards track for consideration as a 
> Proposed Standard in a week or two. Except for the fact that this is not 
> an official WG document for either WebDAV or HTTP, this constitutes kind 
> of a WG last call.
> 
> All the feedback so far in both groups has been great but because 
> there's been fairly close review I don't expect a lot more changes. I'm 
> still hoping to hear from people who intend to implement this if it 
> becomes an RFC.
> 
> Lisa


OK, here are my updated comments:


C-03-02, Section 2

"This specification only defines usage of the platform-portable gdiff
[9] format identified as 'application/gdiff'."

As far as I can tell, there is no registration for "application/gdiff". 
Options:

1) do the registration in this RFC (appendix)
2) have a separate RFC for the gdiff format, including a registration
3) workaround the issue by saying that in the absence of a MIME type, 
the gdiff
format is assumed
4) ...?

(Personal preference: #1)

-04 update: I hear that Lisa is trying to get the MIME type registered. 
I don't think this will work as long as the documentation only resides 
in a W3C note. If PATCH is really to become an IETF standards-track 
document at some point of time, normative parts of it (like the GDIFF 
documentation) need to live in an acceptable place; I don't think a 
vendor note to the W3C is suitable; for instance, what do we know about 
IP issues with it?


C-03-08, Section 3.2.2

2) Make this optional for servers that do not care about WebDAV.

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/

-05 update: Right now it's unclear whether this is normative. If it is,
the reference to RFC3253 needs to be moved into the Normative References
section.


E-05-01, Abbreviations

...should be expanded the first time they appear in the next.


E-05-02, Security considerations

The one mentioned doesn't seem to be a *Security* consideration at all. 
It's more about correctness/robustness, isn't it?
Received on Thursday, 2 September 2004 18:27:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:35 GMT