Re: [apps-discuss] Applications Directorate Review of draft-desruisseaux-caldav-sched-11

[Julian Reschke <[e-mail]>]

On 2012-03-08 14:18, Eliot Lear wrote:
>
>
> On 3/8/12 1:35 PM, Julian Reschke wrote:
>> On 2012-03-08 11:40, Eliot Lear wrote:
>>> ...
>>>>     This document inherits, and sometimes extends, DTD productions from
>>>>     Section 14 of [RFC4918].
>>>
>>> I would reword- "This document inherits and extends DTD productions..."
>>>
>>> If so, should this specification update RFC4918 in rfc-index.txt?
>>
>> This is similar to other specs building on WebDAV, and we haven't done
>> that (saying "updates") before.
>>
>>> §2.1.1, pg 11, and similar text in §2.2.1, pg 13, §2,4,1, pg 14, and
>>> similar:
>>>
>>>>     PROPFIND behavior:  This property SHOULD NOT be returned by a
>>>>        PROPFIND allprop request (as defined in Section 14.2 of
>>>>        [RFC4918]).
>>>
>>> Why SHOULD NOT and not MUST NOT?  How should the client interpret the
>>> information, if returned?
>>
>> SHOULD NOT is right; returning it does no harm. Also, it's consistent
>> with other WebDAV specs. Having SHOULD NOT in one place and MUST NOT
>> somewhere else would be awkward.
>
> Great.  What's the client behavior if it sees it?

Essentially, the client didn't ask for the property but the server has 
sent it anyway. The client can throw it away, or keep it for later use 
(the latter case would be an edge case, because if the client had been 
interested, it would have asked for the property right away).

>>> Throughout:
>>>
>>> Tables should be numbered for reference.
>>
>> If this is supposed to be a general rule, I would object to it. It's a
>> matter of style, and thus should be discussed in the RFC style manual,
>> if it ever gets updated.
>
> No it's not.  It's for internal referencing.

I just checked the spec and couldn't see any case where the tables being 
numbered would have made referencing them easier.

IMHO, "the table below" is more helpful as "table NN" and then having 
the tables being numbered. Things would be different if the references 
were more complex, or in a more complex presentation where tables might 
be moved around (which we do not do in RFCs).

Best regards, Julian


-- 
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782