Re: PATCH Draft

Lisa Dusseault wrote:
>>> No.   A streamed patch or a diff format where it's desirable could
>>> override this requirement.  The possibility of such a format or
>>> extension should not induce us to leave this variation open.
>>
>> What do you mean by "override"?  It's a MUST.
> 
> I mean that if I write RFC 6666 saying that "A WG chair MUST wear a 
> green hat", and we get IETF consensus on that, then that's the requirement.
> 
> Later on if you write RFC 7777 saying that "An exception to the 
> requirement in RFC6666 that WG chairs wear green hats is when the WG 
> chair has no hair and can paint their head green.  The introduction of 
> head painting techniques in this document motivates the change in 
> requirements."
> 
> The first requirement was made before head painting was introduced, so 
> it was correct for its day.  The later RFC updates and overrides the 
> earlier RFC.
> 
> We don't need to write RFCs that allow for any possible future RFC 
> wording.  The future RFCs can handle themselves :)
> 
> It's "borrowing trouble", as my grandmother would say, to anticipate the 
> future too much when there are ways of dealing with the future when it 
> arrives.  The case to worry about is when implementations might be 
> written that would too strongly prevent the introduction of future 
> improvements.  This is not such a case because if in the future somebody 
> defines a streamed patch, then servers and clients have to implement 
> that streamed patch as well as deal with the changed atomicity 
> requirements.

Understood, but IMHO still a bad idea.

My understanding was that we'll have a single place that defines the 
PATCH method, and many other places that define potential patch formats. 
The latter ones in general will be just description of formats with MIME 
type registrations.

If the PATCH method would be defined in a way so that we *expect* a 
future patch format may to have to obsolete it then we IMHO have done a 
bad design decision.

>>> > "Therefore, the client MUST verify that it is applying the delta
>>> > encoding to a known entity by first acquiring the strong ETag [...]"
>>> >
>>> > I don't see why this is required.  Of course, if the client wants the
>>> > guarantees provided by strong etags, it can get them.  But why does
>>> > that matter to a protocol specification?  Suggest removal of that
>>> > paragraph.
>>>
>>> Why remove it?  What's the harm in making this requirement that
>>> clients behave properly?
>>
>> How can a spec prescribe that clients behave properly?
> 
> The same way it prescribes that servers behave properly: it provides a 
> social mechanism justifying you in pointing and shaking your finger at 
> an implementor.  Not all requirements can or need be verified through 
> automated testing.

-1 on making things a MUST requirement for which we know that they are 
not always useful.

>> Because that interpretation of Allow isn't licensed by RFC 2616.
> 
> I disagree with your interpretation of Holy Writ :)
> 
>    "The Allow entity-header field lists the set of methods supported
>       by the resource identified by the Request-URI."
> 
> The use of passive voice instead of requirements language is 
> unfortunate, but is more likely to imply MUST than MAY.

I agree that RFC2616 requires the Allow header to contain PATCH in this 
case. On the other hand, I strongly disagree with the PATCH spec making 
a normative requirement on something that is already defined in RFC2616. 
Just be either silent, or just mention it (for instance in an example), 
but by all means do not have yet another new normative requirement here.

Best regards, Julian

Received on Friday, 6 July 2007 06:33:21 UTC