- From: Ted Hardie <hardie@qualcomm.com>
- Date: Mon, 20 Sep 2004 15:11:42 -0700
- To: Julian Reschke <julian.reschke@gmx.de>, w3c-dist-auth@w3.org, Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
- Cc: w3c-dist-auth-request@w3.org
At 2:33 PM +0200 9/17/04, Julian Reschke wrote: >Hi, > >a recent discussion on the Atom mailing list reminded me to check >how the BIND spec currently defines "sameness" of resources [1]: > >"If the values of DAV:resource-id returned by PROPFIND requests >through two bindings are identical, the client can be assured that >the two bindings are to the same resource." > >The (potential) issue here is although the spec says "indentical", >people may believe that assumptions about specific URI equivalence >rules are allowed. For instance, or the following URIs identical? > >"opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8" >"Opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8" >"opaquelocktoken:f81d4fae%2d7dec-11d0%2da765%2d00a0c91e6bf8" >"opaquelocktoken:f81d4fae%2D7dec-11d0%2da765%2D00a0c91e6bf8" > >This is already non-trivial when only considering a single URI >scheme, but it get's very hairy with multiple schemes. > >Proposal: clarify that "identical" means "identical character-by-character". > >Best regards, Julian > opaquelocktoken is defined in 2518, at least if I am reading the URI scheme registrations at IANA correctly. Are you planning to update 2518? If so, do you plan to change the generation reference from the UUID reference (ISO 11578) to something else? As it stands now, I would expect implementations to treat to tokens as equivalent if the UUID would be equivalent. Note as well that equivalence of the scheme name (Opaquelocktoken vs. opaquelocktoken) is different to the equivalence of the token. 2396bis defines the scheme as case-insensitive, even though the canonical form is lower case. regards, Ted Hardie
Received on Monday, 20 September 2004 22:12:37 UTC