W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2003

RE: URI scheme uniqueness

From: <hardie@qualcomm.com>
Date: Mon, 11 Aug 2003 16:01:21 -0700
Message-Id: <p06001a06bb5dcf666e62@[205.214.163.32]>
To: "Lisa Dusseault" <lisa@xythos.com>, "'Julian Reschke'" <julian.reschke@gmx.de>, <w3c-dist-auth@w3.org>

>Lisa Dusseault writes:
>>  I suspect that this presumes something about the way clients
>>  should behave; to wit, if they get a lock token DAV:1234
>>  issued by server dav.example.com, they will not get whacked
>>  out when they get a lock token DAV:1234 issued by server
>>  dav.example.net (obviously, for some other resource).  I
>>  believe that this would be good engineering, obviously, but I
>>  think maintaining a stricter requirement is useful.
>
>I think that although we have the uniqueness requirement already
>(it can't be made stricter very easily) clients simply can't assume
>that lock tokens really are globally unique. 
>
>Should we add some client advice to RFC2518bis, saying that in
>practice clients cannot assume that lock tokens will be unique
>across servers and should not be used as unique lookups in client
>code? It provides little advantage to the client to assume
>uniqueness, and it could be an easy source of bugs.  This falls
>under the IETF principle of being generous in what you accept
>(non-unique tokens) but strict in what you generate (unique only).
>
>

It's always tricky to write that sort of text without weakening the
core requirement, but it is possible.  Usually it falls under the "fail
gracefully" rubric--in other words, saying that clients which receive
the same lock token a second time should neither accept it nor
crash, but do something else which allows them to fail gracefully.
Given the potential uses here, though, I'm not sure what the "graceful
failure" mode is.  What would you suggest the right behavior is in
that case?
			regards,
				Ted
Received on Monday, 11 August 2003 19:01:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:04 GMT