Lisa Dusseault | 9 Jul 18:56 2009
Picon

BIND, lock root, and clarifying RFC4918


I've been discussing the BIND draft's appendix A <http://tools.ietf.org/html/draft-ietf-webdav-bind-25#appendix-A> with Julian, and he asked me to post my opinion publicly.

There are two possible meanings when we discuss "the root of a lock":  this could refer to the resource that was directly locked, or to the URL that was addressed in the LOCK request.  There are cases where RFC4918 definitely uses this phrase to mean resource: "The resource identified in the Request-URI becomes the root of the lock.".  (<http://tools.ietf.org/html/rfc4918#section-7.4>)

The appendix to BIND "clarifies" this by contradicting it, and saying that the lock root is actually the URI.  (Certainly I agree the value of the 'lock-root' element is the URI so at least that's not controversial.)  This "clarification" is justified by needing to explain that the lock does not cover the URIs that are bindings to the resource, other than the URI that was LOCKed.    I don't think there is a need to change the words of 4918 or clarify them; the behavior of bindings can be specified in BIND without that.

With bindings functionality as Julian explains it in email, you can send an UNLOCK request to any binding of a locked resource, even though some of those bindings aren't covered by the lock.  You can also change a binding that's not covered by the lock, so if you lock a resource through a binding in your collection, I can change the name of the binding to the same resource in my collection or remove it.  This behavior makes at least as much sense as any other, but it should be explained explicitly.  I don't think it falls out of the model trivially the same way for everybody reading the BIND document. 

Sometimes with messy, deployed protocols and extensions, it's hard to define a model such that all the behavior simply can be deduced from the model.  Sometimes you have to actually say "it works this way" although it also helps to have the model.

To be clear, since BIND is an experimental document, I think this appendix is pretty harmless to everything except possibly the interoperability of bindings implementations, so I'm not blocking the document or doing anything other than explain my lack of complete agreement.

Lisa
Geoffrey M Clemm | 9 Jul 20:22 2009
Picon

Re: BIND, lock root, and clarifying RFC4918


The term "lock-root" is introduced and very clearly defined in section 6.1 (Lock Model) to be a URI:

A resource becomes directly locked when a LOCK request to a URL of that resource creates a new lock.
The "lock-root" of the new lock is that URL.  

There are four other occurrences of "lock-root", or "root of the lock" that make it equally clear that the root of a lock is a URI:

Section 6.1 (Lock Model):
If a request causes the lock-root of any lock to become an unmapped URL,

Section 7 (Write Lock):
The list of modifications covered by a write-lock include: ... A modification of the mapping of the root of the write lock,  either to another resource or to no resource

Section 7.4 (Write Locks and Collections):
With a depth-infinity lock, the resource identified by the root of the lock is directly locked

Section 14.12 (lockroot XML Element):
   Name:   lockroot
  Purpose:   Contains the root URL of the lock, which is the URL through which the resource was addressed in the LOCK request.

In section 9.10.1 (not section 7.4), we have the first and only mis-use of the term that was quoted by Lisa:
The resource identified in the Request-URI becomes the root of the lock.

It should have said just "The Request-URI becomes the root of the lock."  

I don't see how anyone could conclude that there are "two possible meanings" of the term lock root.
This single mis-use of the term is clearly just a bug in RFC-4918 that needs to be fixed.

Cheers,
Geoff


Lisa Dusseault wrote on 07/09/2009 12:56:22 PM:

> I've been discussing the BIND draft's appendix A <http://
> tools.ietf.org/html/draft-ietf-webdav-bind-25#appendix-A> with
> Julian, and he asked me to post my opinion publicly.
>
> There are two possible meanings when we discuss "the root of a
> lock":  this could refer to the resource that was directly locked,
> or to the URL that was addressed in the LOCK request.  There are
> cases where RFC4918 definitely uses this phrase to mean resource:
> "The resource identified in the Request-URI becomes the root of the
> lock.".  (<http://tools.ietf.org/html/rfc4918#section-7.4>)
>
> The appendix to BIND "clarifies" this by contradicting it, and
> saying that the lock root is actually the URI.  (Certainly I agree
> the value of the 'lock-root' element is the URI so at least that's
> not controversial.)  This "clarification" is justified by needing to
> explain that the lock does not cover the URIs that are bindings to
> the resource, other than the URI that was LOCKed.    I don't think
> there is a need to change the words of 4918 or clarify them; the
> behavior of bindings can be specified in BIND without that.
>
> With bindings functionality as Julian explains it in email, you can
> send an UNLOCK request to any binding of a locked resource, even
> though some of those bindings aren't covered by the lock.  You can
> also change a binding that's not covered by the lock, so if you lock
> a resource through a binding in your collection, I can change the
> name of the binding to the same resource in my collection or remove
> it.  This behavior makes at least as much sense as any other, but it
> should be explained explicitly.  I don't think it falls out of the
> model trivially the same way for everybody reading the BIND document. 
>
> Sometimes with messy, deployed protocols and extensions, it's hard
> to define a model such that all the behavior simply can be deduced
> from the model.  Sometimes you have to actually say "it works this
> way" although it also helps to have the model.
>
> To be clear, since BIND is an experimental document, I think this
> appendix is pretty harmless to everything except possibly the
> interoperability of bindings implementations, so I'm not blocking
> the document or doing anything other than explain my lack of
> complete agreement.
>
> Lisa
Julian Reschke | 13 Jul 13:45 2009
Picon
Picon

Re: Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt]

Bernard Desruisseaux wrote:
> Cyrus and I submitted draft-desruisseaux-caldav-sched-07 to the IETF 
> last week.  See Internet-Draft announcement below.
> 
> Before requesting the IESG to consider this Internet-Draft as a Proposed 
> Standard, we would like to get as much feedback as possible from the 
> participants of the "caldav" mailing list as well as from the members of 
> the WebDAV and Calsify Working Groups.
> 
> Please review the document and send your comments to the caldav <at> ietf.org 
> mailing list by July 7th, 2009.
> 
> We would like to submit draft -08 before July 13, 2009, i.e., the final 
> submission cut-off for the 75th IETF in Stockholm, Sweden.
> ...

Hi Bernard,

I'm sorry that I'm late with my feedback (attached below). Most are nits 
of editorial nature. Also, I have only read the spec from an HTTP/WebDAV 
point of view, as I'm no expert on calendaring at all.

There is a single non-editorial issue I found, and that is the 
introduction of the scheduling tag, with associated HTTP headers. I 
think it would be good to discuss this in more detail.

BR, Julian

--- snip ---
1.5.  XML Namespaces and Processing

    Definitions of XML elements in this document use XML element type
    declarations (as found in XML Document Type Declarations), described
    in Section 3.2 of [W3C.REC-xml-20081126].

JR: should this be a section reference?

    The XML declarations used in this document do not include namespace
    information.  Thus, implementers must not use these declarations as
    the only way to create valid CalDAV properties or to validate CalDAV
    XML element type.  Some of the declarations refer to XML elements

JR: I realize this sentence is borrowed from 4791. Does anybody recall what
the "...create valid CalDAV properties..." refers to? What does the DTD have
to do with that?

4.1.  Scheduling Outbox Collection

    While there is currently no defined use for child resources in a
    scheduling Outbox collection, a scheduling Outbox collection MAY
    contain child resources.

JR: may say "...MAY contain child resources, whose semantics are 
undefined for now..."?
...if this is correct, is it planned to add semantics later? How?

4.2.  Scheduling Inbox Collection

    Scheduling Inbox collections MUST only contain calendar object
    resources that obey the restrictions specified in iTIP
    [I-D.ietf-calsify-2446bis].  Consequently, scheduling Inbox
    collections MUST NOT contain any types of collection resources.
    Restrictions defined in Section 4.1 of CalDAV "calendar-access"
    [RFC4791] on calendar object resources contained in calendar
    collections (e.g., "UID" uniqueness) don't apply to calendar object
    resources contained in a scheduling Inbox collection.  Multiple
    calendar object resources contained in a scheduling Inbox collection
    MAY have the same "UID" property value (i.e., multiple scheduling
    messages for the same calendar component).

JR: last sentence just seems to rephrase the previous one. So maybe say 
"Thus, ..."
and remove the RFC2119 keyword.

5.1.  Identifying Scheduling Object Resources

    Calendar object resources on which the server performs automatic
    scheduling transactons are refered to as scheduling object resources.

JR: spelling.

5.2.1.1.  Create

    The attempt to deliver the scheduling message will either succeed or
    fail.  In all cases, the server MUST add a "SCHEDULE-STATUS"
    iCalendar property parameter (see Section 10.3) to the "ATTENDEE"
    iCalendar property in the scheduling object resource being created,
    and set its value as described in Section 9.2.  This will result in
    the created calendar object resource differing from the calendar data
    sent in the HTTP request.  As a result clients MAY reload the
    calendar data from the server as soon as it is created on the server
    in order to update to the new server generated state information.

The "MAY" doesn't seem to be right here. This is not an interop requirement
but simply a statement of fact. They "MAY" reload whenever they want
anyway :-) (there are more occurrences of this language later on).

7.2.7.  CALDAV:max-resource-size Precondition

    Name:  max-resource-size

    Namespace:  urn:ietf:params:xml:ns:caldav

    Apply to:  POST

    Use with:  403 Forbidden

    Purpose:  (precondition) -- The resource submitted in the POST
       request MUST have an octet size less than or equal to the value of

JR: "octet size"? I thought that's 8 :-) Maybe "size in octets"?

8.  Conditional Requests on Scheduling Object Resources

    In order to do that, this specification introduces a new WebDAV
    resource property CALDAV:schedule-tag with a corresponding response
    header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request
    header to allow client changes to be appropriately merged with server
    changes in the case where the changes on the server were the result
    of an "inconsequential" scheduling message update.  An
    "inconsequential" scheduling message is one which simply updates the
    status information of Attendees due to a reply from an Attendee.

JR: that sounds really heavy-weight; I think it would be good to discuss
this scenario over on the HTTPbis working group's mailing list. Even if new
state tokens need to be added it is not totally clear why the RFC4918
can not be used for checking.

11.1.  Schedule-Reply Request Header

       Schedule-Reply = "Schedule-Reply" ":" ("T" | "F")

    Example:

       Schedule-Reply: F

    When an Attendee executes an HTTP DELETE request on a scheduling
    object resource, and the Schedule-Reply header is not present, or
    present and set to the value "T", the server MUST send an appropriate
    reply scheduling message with the Attendee's "PARTSTAT" iCalendar
    property parameter value set to "DECLINED" as part of its normal
    automatic scheduling transaction processing.

JR: is this header really really needed? Would it be possible to pass
that information in the request body instead?

Julian Reschke | 13 Jul 22:12 2009
Picon
Picon

Re: Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt]

Julian Reschke wrote:
> ...
> 8.  Conditional Requests on Scheduling Object Resources
> 
>    In order to do that, this specification introduces a new WebDAV
>    resource property CALDAV:schedule-tag with a corresponding response
>    header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request
>    header to allow client changes to be appropriately merged with server
>    changes in the case where the changes on the server were the result
>    of an "inconsequential" scheduling message update.  An
>    "inconsequential" scheduling message is one which simply updates the
>    status information of Attendees due to a reply from an Attendee.
> 
> JR: that sounds really heavy-weight; I think it would be good to discuss
> this scenario over on the HTTPbis working group's mailing list. Even if new
> state tokens need to be added it is not totally clear why the RFC4918
> can not be used for checking.
> ...

Sorry. I meant to say: "...why the RFC4918 'If' header can not be used...".

BR, Julian

Julian Reschke | 14 Jul 14:43 2009
Picon
Picon

Re: Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt]

Julian Reschke wrote:
> Julian Reschke wrote:
>> ...
>> 8.  Conditional Requests on Scheduling Object Resources
>>
>>    In order to do that, this specification introduces a new WebDAV
>>    resource property CALDAV:schedule-tag with a corresponding response
>>    header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request
>>    header to allow client changes to be appropriately merged with server
>>    changes in the case where the changes on the server were the result
>>    of an "inconsequential" scheduling message update.  An
>>    "inconsequential" scheduling message is one which simply updates the
>>    status information of Attendees due to a reply from an Attendee.
>>
>> JR: that sounds really heavy-weight; I think it would be good to discuss
>> this scenario over on the HTTPbis working group's mailing list. Even 
>> if new
>> state tokens need to be added it is not totally clear why the RFC4918
>> can not be used for checking.
>> ...
> 
> Sorry. I meant to say: "...why the RFC4918 'If' header can not be used...".
> 
> BR, Julian

Expanding on that...:

The spec currently introduces a new type of etag, the "schedule-tag", 
exposed as a live WebDAV property, and a new HTTP response header, plus 
a new conditional HTTP request header.

WebDAV (RFC 4918) however already supports "state tokens" in the "If" 
header; right now only lock tokens are used, but there is no reason why 
a protocol wouldn't be able to introduce new state tokens, and allow 
them to be checked using the "If" header. -- That would at least avoid 
introducing a new conditional request header.

That being said, it would be nice to get rid of the new state tokens ( 
schedule tags altogether.

I do understand the problem with many clients updating the attendee 
information simultaneously.

Two thoughts on this:

1) In general, issues like that can be avoided by enhancing the 
granularity of the resource that needs to be updated. For instance, the 
status for each attendee could be modeled as a separate resource, that 
could then respond to GET/PUT/DELETE. (I guess the server could 
advertise its URL as a parameter on the ATTENDEE).

2) It may also be possible to use PATCH for updating the attendee 
status; we would just need to define a simple payload format which can 
guard the client from unintentionally changing the status on an event 
that just changed (my understanding is that PATCH is likely to be 
finished in time for this spec).

Best regards, Julian

Bernard Desruisseaux | 14 Jul 21:33 2009
Picon

Re: Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt]

Hi Julian,

After our offline discussion here's a summary of the changes we will do (see comments inline below)

Thanks a lot for your review!

Cheers,
Bernard

Julian Reschke wrote:
Bernard Desruisseaux wrote:
Cyrus and I submitted draft-desruisseaux-caldav-sched-07 to the IETF last week.  See Internet-Draft announcement below.

Before requesting the IESG to consider this Internet-Draft as a Proposed Standard, we would like to get as much feedback as possible from the participants of the "caldav" mailing list as well as from the members of the WebDAV and Calsify Working Groups.

Please review the document and send your comments to the caldav <at> ietf.org mailing list by July 7th, 2009.

We would like to submit draft -08 before July 13, 2009, i.e., the final submission cut-off for the 75th IETF in Stockholm, Sweden.
...

Hi Bernard,

I'm sorry that I'm late with my feedback (attached below). Most are nits of editorial nature. Also, I have only read the spec from an HTTP/WebDAV point of view, as I'm no expert on calendaring at all.

There is a single non-editorial issue I found, and that is the introduction of the scheduling tag, with associated HTTP headers. I think it would be good to discuss this in more detail.

BR, Julian

--- snip ---
1.5.  XML Namespaces and Processing

   Definitions of XML elements in this document use XML element type
   declarations (as found in XML Document Type Declarations), described
   in Section 3.2 of [W3C.REC-xml-20081126].

JR: should this be a section reference?

   The XML declarations used in this document do not include namespace
   information.  Thus, implementers must not use these declarations as
   the only way to create valid CalDAV properties or to validate CalDAV
   XML element type.  Some of the declarations refer to XML elements

JR: I realize this sentence is borrowed from 4791. Does anybody recall what
the "...create valid CalDAV properties..." refers to? What does the DTD have
to do with that?
We will modify Section 1.5 to use the same text as currently specified in Section 2 of vCard Extensions to WebDAV (CardDAV).


4.1.  Scheduling Outbox Collection

   While there is currently no defined use for child resources in a
   scheduling Outbox collection, a scheduling Outbox collection MAY
   contain child resources.

JR: may say "...MAY contain child resources, whose semantics are undefined for now..."?
...if this is correct, is it planned to add semantics later? How?
We will change the text to specify that the use of child resources is reserved for future revisions or extensions of this specifications.


4.2.  Scheduling Inbox Collection

   Scheduling Inbox collections MUST only contain calendar object
   resources that obey the restrictions specified in iTIP
   [I-D.ietf-calsify-2446bis].  Consequently, scheduling Inbox
   collections MUST NOT contain any types of collection resources.
   Restrictions defined in Section 4.1 of CalDAV "calendar-access"
   [RFC4791] on calendar object resources contained in calendar
   collections (e.g., "UID" uniqueness) don't apply to calendar object
   resources contained in a scheduling Inbox collection.  Multiple
   calendar object resources contained in a scheduling Inbox collection
   MAY have the same "UID" property value (i.e., multiple scheduling
   messages for the same calendar component).

JR: last sentence just seems to rephrase the previous one. So maybe say "Thus, ..."
and remove the RFC2119 keyword.
Will add "Thus," and change MAY to "can".

5.1.  Identifying Scheduling Object Resources

   Calendar object resources on which the server performs automatic
   scheduling transactons are refered to as scheduling object resources.

JR: spelling.
s/transactons are refered/transactions are referred/


5.2.1.1.  Create

   The attempt to deliver the scheduling message will either succeed or
   fail.  In all cases, the server MUST add a "SCHEDULE-STATUS"
   iCalendar property parameter (see Section 10.3) to the "ATTENDEE"
   iCalendar property in the scheduling object resource being created,
   and set its value as described in Section 9.2.  This will result in
   the created calendar object resource differing from the calendar data
   sent in the HTTP request.  As a result clients MAY reload the
   calendar data from the server as soon as it is created on the server
   in order to update to the new server generated state information.

The "MAY" doesn't seem to be right here. This is not an interop requirement
but simply a statement of fact. They "MAY" reload whenever they want
anyway :-) (there are more occurrences of this language later on).
s/MAY/can/




7.2.7.  CALDAV:max-resource-size Precondition

   Name:  max-resource-size

   Namespace:  urn:ietf:params:xml:ns:caldav

   Apply to:  POST

   Use with:  403 Forbidden

   Purpose:  (precondition) -- The resource submitted in the POST
      request MUST have an octet size less than or equal to the value of

JR: "octet size"? I thought that's 8 :-) Maybe "size in octets"?
Yes.



8.  Conditional Requests on Scheduling Object Resources

   In order to do that, this specification introduces a new WebDAV
   resource property CALDAV:schedule-tag with a corresponding response
   header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request
   header to allow client changes to be appropriately merged with server
   changes in the case where the changes on the server were the result
   of an "inconsequential" scheduling message update.  An
   "inconsequential" scheduling message is one which simply updates the
   status information of Attendees due to a reply from an Attendee.

JR: that sounds really heavy-weight; I think it would be good to discuss
this scenario over on the HTTPbis working group's mailing list. Even if new
state tokens need to be added it is not totally clear why the RFC4918
can not be used for checking.

We will modify the text to make it clear that If-Schedule-Tag-Match is more than a conditional header, i.e., the server is required to resolve conflicts when this request header is specified.



11.1.  Schedule-Reply Request Header


      Schedule-Reply = "Schedule-Reply" ":" ("T" | "F")

   Example:

      Schedule-Reply: F

   When an Attendee executes an HTTP DELETE request on a scheduling
   object resource, and the Schedule-Reply header is not present, or
   present and set to the value "T", the server MUST send an appropriate
   reply scheduling message with the Attendee's "PARTSTAT" iCalendar
   property parameter value set to "DECLINED" as part of its normal
   automatic scheduling transaction processing.

JR: is this header really really needed? Would it be possible to pass
that information in the request body instead?

We would like to avoid defining a new request body just for that purpose.  As discussed, this request header can also be specified on the MOVE method.  BTW, we will clarify the text to specify that this request header applies to any "removal" operation, i.e., DELETE or  MOVE request directly targeted at a resource or targeted at any parent of a resource (e.g., DELETE on calendar collection).

Thanks,
Bernard
Julian Reschke | 15 Jul 12:19 2009
Picon
Picon

On the use of weak ETags for authoring

Hi,

it appears that there is some confusion about the usability of weak 
ETags for write operations, so it seems to me that it would be useful to 
summarize what the relevant specs say, and what changes we have made in 
HTTPbis so far...

1) Weak etags in non-GET requests

Historically, RFC2616 did not allow clients to perform conditional 
requests with weak etags for methods other than GET/HEAD (see 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.13.3.3>). 
That's a restriction that didn't make a lot of sense, as the server is 
in full control over which types of etags it generates, their semantics, 
and how it supports them in conditional requests. For instance, if the 
server does generate weak ETags, but does not want to support them in a 
PUT/If-Match, it will reject those requests with a 4xx status anyway.

So we relaxed this rule around a year ago (see 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/116>). The only 
restriction that stayed is related to byte-range requests (where you 
really really want a strong etag as validator).

2) Weak ETags in WebDAV

Related to this, WebDAV defines an additional conditional header called 
"If" (<http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.10.4>), 
which never had the restriction mentioned above. So protocols that 
extend WebDAV already can use weak ETags in write requests.

3) Matching weak ETags

At least one popular HTTP server (in some configurations) assigns a weak 
ETag when a resource is created/updated, and only promotes it to a 
strong ETag later on (due to being based on a file system time stamp).

With <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/71>, also 
changed around a year ago, we have clarified that these two variants 
indeed match (weakly), and thus can be used in case where weak matches 
are sufficient.

This is a spec change that some have missed, so in doubt please review 
that you are ok with the current text in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p4-conditional-07.html#rfc.section.4.p.7>:

-- snip --
  The only function that HTTP/1.1 defines on validators is comparison.
    There are two validator comparison functions, depending on whether
    the comparison context allows the use of weak validators or not:

    o  The strong comparison function: in order to be considered equal,
       both opaque-tags MUST be identical character-by-character, and
       both MUST NOT be weak.

    o  The weak comparison function: in order to be considered equal,
       both opaque-tags MUST be identical character-by-character.

    The example below shows the results for a set of entity tag pairs,
    and both the weak and strong comparison function results:

    +--------+--------+-------------------+-----------------+
    | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
    +--------+--------+-------------------+-----------------+
    | W/"1"  | W/"1"  | no match          | match           |
    | W/"1"  | W/"2"  | no match          | no match        |
    | W/"1"  | "1"    | no match          | match           |
    | "1"    | "1"    | match             | match           |
    +--------+--------+-------------------+-----------------+
-- snip --

Best regards, Julian

Julian Reschke | 16 Jul 16:00 2009
Picon
Picon

Re: [APPS-REVIEW] Request for Apps Area review for draft-ietf-vcarddav-webdav-mkcol-05.txt

FYI - more reviews from the WebDAV community wouldn't hurt either...

BR, Julian

Alexey Melnikov wrote:
> Hi,
> Vcarddav WG is about to send draft-ietf-vcarddav-webdav-mkcol-05.txt for 
> AD review. Julian Reschke <julian.reschke <at> greenbytes.de> who is going to 
> shepherd the document thought that it would benefit for additional 
> review outside of the WG.
> 
> So I would appreciate an Apps Area review of this document.
> 
> Thanks,
> Alexey
> 
> _______________________________________________
> APPS-REVIEW mailing list
> APPS-REVIEW <at> ietf.org
> https://www.ietf.org/mailman/listinfo/apps-review
> 

Henrik Nordstrom | 17 Jul 04:14 2009
Picon

Re: On the use of weak ETags for authoring

ons 2009-07-15 klockan 12:19 +0200 skrev Julian Reschke:

> With <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/71>, also 
> changed around a year ago, we have clarified that these two variants 
> indeed match (weakly), and thus can be used in case where weak matches 
> are sufficient.
> 
> This is a spec change that some have missed, so in doubt please review 
> that you are ok with the current text in 
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p4-conditional-07.html#rfc.section.4.p.7>:

Just to be clear, the text only clarifies what RFC2616 already said.
There is no actual change in the comparision function, just different
wording.

Regarding wording I think the explicit mention of weakness should be
added back to the weak comparison function as it adds clarity to those
who don't quite remember that opaque-tag do not include the weakness
indicator (this is defined many sections away).

From:

      * The weak comparison function: in order to be considered equal,
        both opaque-tags MUST be identical character-by-character.

To:

      * The weak comparison function: in order to be considered equal,
        both opaque-tags MUST be identical character-by-character, but
        either or both of them MAY be tagged as "weak" without affecting
        the result.

Regards
Henrik

Julian Reschke | 17 Jul 17:55 2009
Picon
Picon

Re: On the use of weak ETags for authoring

Henrik Nordstrom wrote:
> Just to be clear, the text only clarifies what RFC2616 already said.
> There is no actual change in the comparision function, just different
> wording.
> 
> Regarding wording I think the explicit mention of weakness should be
> added back to the weak comparison function as it adds clarity to those
> who don't quite remember that opaque-tag do not include the weakness
> indicator (this is defined many sections away).
> 
> From:
> 
>       * The weak comparison function: in order to be considered equal,
>         both opaque-tags MUST be identical character-by-character.
> 
> To:
> 
>       * The weak comparison function: in order to be considered equal,
>         both opaque-tags MUST be identical character-by-character, but
>         either or both of them MAY be tagged as "weak" without affecting
>         the result.

Yes, I agree we went a bit too far when rephrasing it; I've committed 
your proposed change as 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/610>.

BR, Julian


Gmane