Date: Tue, 5 Oct 1999 13:03:36 -0400 Message-Id: <9910051703.AA14121@tantalum> From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com> To: ietf-dav-versioning@w3.org In-Reply-To: <1999Oct05.123200.1250.1342211@otismtp.ott.oti.com> Subject: Revision identifier and revisions label namespace sharing <gmc/> Some of the earlier drafts of the protocol did require that revision identifiers and revision labels share the same namespace. Since the revision identifiers are server-defined, this provides a significant interoperability barrier, since a client would have to know the revision identifier naming conventions of all servers it might work against in order to avoid a name clash between a label it wants to create and all server identifiers that it might clash with. <gmc/> So I believe the current protocol is correct in not sharing namespaces between revision identifiers and revision labels. This should be made clear in the protocol specification. From: Jeff_McAffer@oti.com (Jeff McAffer OTT) <tpe> I can easily imagine revision selectors being Integers -- these would collide with labels that are equivalent String form of Integers; i.e. revisionid: 3 label: 3 </tpe> <jra> The revision could never been labeled "3" as this conflicts with an existing revision name. </jra> <jm> A couple things to note. 1) The spec currently does not state this. revision-ids are described as unique amongst the set of other revision-ids on a resource but labels are much more weakly defined. <gmc/> Labels are also guaranteed to be unique amongst the set of other labels on a resource (since it is a revision name, and revision names are defined to have this property). 2) If names are in fact unique, then why do we have rsr-label and rsr-revision-id elements? There should just be an rsr-name element as a names are labels or revision-ids. </jm> <gmc/> These elements were defined under the assumption that they are separate namespaces. If we changed that assumption, I agree that we should just have an rsr-name element. Cheers, Geoff