Subject: [Bug 50] Property teminology inconsistent with RFC3253

From: [email-masked]
Date: Sun, 18 Dec 2005 07:24:05 -0800

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=50

------- Additional Comments From [email-masked]  2005-12-18 07:24 -------
Here's the proposed change (see also
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz050>):

Section 14., para. 2:
OLD:

    Some property values are calculated by the server and it is not
    appropriate to allow client changes, thus they are protected.
    Existing server implementations already have different sets of
    RFC2518 properties protected, but clients can have some expectations
    which properties are normally protected.  The value of a protected
    property may not be changed even by a user with permission to edit
    other properties.  The value of an unprotected property may be
    changed by some users with appropriate permissions.

NEW:

    When a property of a specific kind of resource is "protected", the
    property value cannot be updated on that kind of resource except by a
    method explicitly defined as updating that specific property.  In
    particular, a protected property cannot be updated with a PROPPATCH
    request.  Note that a given property can be protected on one kind of
    resource, but not protected on another kind of resource.
 
    When a property is "computed", its value is defined in terms of a
    computation based on the content and other properties of that
    resource, or even of some other resource.  A computed property is
    always a protected property.

Section 14., para. 17:
OLD:

    Protected:  SHOULD NOT be protected

NEW:

    Protected:  SHOULD NOT be protected.

Section 14., para. 24:
OLD:

    Value:  language-tag (language-tag is defined in section 14.13 of
       [RFC2616])
    Protected:  SHOULD NOT be protected, so that clients can reset the
       language.

NEW:

    Value:  language-tag (language-tag is defined in section 14.13 of
       [RFC2616])
 
    Protected:  SHOULD NOT be protected, so that clients can reset the
       language.

Section 14., para. 32:
OLD:

    Protected:  SHOULD be protected so clients cannot set to misleading
       values

NEW:

    Protected:  This property is computed, thus protected.

Section 14., para. 39:
OLD:

    Protected:  SHOULD NOT be protected, so clients may fix this value

NEW:

    Protected:  SHOULD NOT be protected, so clients may fix this value.

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.