Re: PATCH Draft

On Jul 4, 2007, at 5:23 PM, Mark Baker wrote:

>
>> > "If the entire delta encoding cannot be successfully applied  
>> then the
>> > server MUST fail the entire request, applying none of the changes"
>> >
>> > Why is this needed?  It would seem to depend upon the diff format.
>> > Plus I could imagine scenarios where it's undesirable (e.g. a  
>> streamed
>> > patch).  Suggest removal.
>>
>> 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.


>
>> > "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.

>
> 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.

Lisa

Received on Thursday, 5 July 2007 20:49:54 UTC