Subject: On the assertion that tag: URI use unreasonably requires authorityName ownership

From: "Bob Wyman" <[email-masked]>
Date: Fri, 3 Sep 2004 15:42:13 -0400

On this list, a number of objections have been made concerning
suggestions that the tag uri scheme would be a suitable convention for
defining appropriately unique atom:ids. These objections include:
	1. Use of the tag: URI requires ownership of a scare resource: the
"authorityName", which is constrained by the current tag URI draft to be one
of a domain name or an email address. The suggestion is that a large number
of potential atom:id generators will not have ownership a domain name or
will not be able to obtain ownership or effective control easily.
	2. While virtually every possible atom:id generator should be able
to obtain an email address, many generators will not be willing to "expose"
their email address due to privacy concerns.
	The second objection is completely reasonable. The first is, I
think, not nearly as strong as presented by the objectors on this list.
	The problem described by the first objection arises when someone has
a blog, or other atom generating application, whose network address has a
form such as:
	http://example.com/foobar/atom.xml
	The problem is that Atom generator is not the owner of the
authorityName "example.com" and thus, it is claimed, can't generate tag
URIs. This objection is, I think, easily eliminated. Actual ownership of the
domain name isn't needed to permit construction of valid tag URIs. All that
is needed is an appropriate delegation of tag generation privileges.
	In the vast majority of cases, the generator that is tied to the URI
above *will have* effective control over uses of a URI fragment such as
"http://example.com/foobar". Such control is sufficient to allow
construction of a tag URI without requiring the generator to register a new
domain name.
	A tag URI has the form:

	tag:authorityName,date:specific

	The "specific" is used to disambiguate tags generated by the
authorityName on the date given.
	A simple extension to this format can be made to exploit or empower
"sub-authorityNames". For instance, consider the following tag:

	tag:example.com,2004-09-03:foobar:something_specific

	It has the form: 

	tag:authorityName,date:sub-authorityName:specific

	What I've done here is prefixed the "specific" element with the http
"Path" data. This results in a tag which is unique, yet which does not
require that the operator of the foobar path actually "own" a domain name.
Assuming that all others who are hosted at example.com follow the same
convention, everyone can easily create unique ids without conflict. 
	This convention for allowing "sub-authorities" to generate tags does
not require any modification to the existing tag URI draft since the
"specific" element is defined broadly enough to permit this usage.
Additionally, it is very cheap to implement.
	Some would object, saying: "But, the owner of the authorityName must
explicitly delegate tag generation authority for this to work." This is, of
course, the case. However, my guess is that such a delegation would be made
in the vast majority of cases given that there are few motivations for
authorities to restrict tag generation ability when they have already
permitted the generation of URI's with the same path element.
	Note: At least one author of the tag URI scheme has said that he's
willing to consider documenting this convention as part of the draft if
there is substantial support for it and evidence that it will solve a
problem.
	The "scarcity" of domain names is not an adequate argument against
the usage of tag URI's as atom:ids.

		bob wyman

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 04 Sep 2004 17:52:59 +0200

On Fri, 3 Sep 2004 15:42:13 -0400, Bob Wyman <[email-masked]> wrote:

> "authorityName", which is constrained by the current tag URI draft to be  
> one of a domain name or an email address. The suggestion is that a large  
> number of potential atom:id generators will not have ownership a domain
> name or will not be able to obtain ownership or effective control easily.

Can't we take this up with the tag: URI authors? If this point makes the  
scheme unusable for Atom, they'd surely listen to us, no?

> to obtain an email address, many generators will not be willing to  
> "expose" their email address due to privacy concerns.

Good point. This should probably also be taken up with the authors.

> the usage of tag URI's as atom:ids.

+1.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 4 Sep 2004 12:06:19 -0400

Asbjørn Ulsberg wrote:
>> "authorityName", which is constrained by the current tag URI draft to
>> be one of a domain name or an email address. The suggestion is that a
>> large number of potential atom:id generators will not have ownership
>> a domain name or will not be able to obtain ownership or effective
>> control easily.
> Can't we take this up with the tag: URI authors? If this point
> makes the scheme unusable for Atom, they'd surely listen to us, no?
	I have, in fact, been discussing these problems and solutions
proposed with the authors of the tag: URI scheme. Important elements of
the proposal I made actually came from Tim Kindberg who is one of the
authors. He is currently awaiting my report on how well this idea is
received by the Atom community and appears willing to consider adding
text to the tag: URI draft that would describe the process of delegating
to sub-Authorities -- if the idea is received well in this forum.
	It appears that Atom's use case is considered significant by the
tag: URI developers. Thus, I expect they will be responsive to our needs
if provided with clear feedback.

		bob wyman

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 04 Sep 2004 18:22:07 +0200

On Sat, 4 Sep 2004 12:06:19 -0400, Bob Wyman <[email-masked]> wrote:

> I have, in fact, been discussing these problems and solutions proposed
> with the authors of the tag: URI scheme. Important elements of the
> proposal I made actually came from Tim Kindberg who is one of the
> authors.

Ah, great.

> He is currently awaiting my report on how well this idea is received by
> the Atom community and appears willing to consider adding text to the
> tag: URI draft that would describe the process of delegating to
> sub-Authorities -- if the idea is received well in this forum.

I at least receive the idea very well. Those who don't should probably  
speak up.

> It appears that Atom's use case is considered significant by the tag:
> URI developers. Thus, I expect they will be responsive to our needs if
> provided with clear feedback.

That sounds very promising.

---

From: Sam Ruby <[email-masked]>
Date: Sat, 04 Sep 2004 14:29:22 -0400

> 	tag:authorityName,date:sub-authorityName:specific

Suggestion:

         tag:authorityName/sub-authorityName,date:specific

Comments:

         ":" and "," in sub-authorityNames must be % encoded.
         "/" is allowed in a sub-authorityName

- Sam Ruby

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 4 Sep 2004 15:46:20 -0400

>         tag:authorityName/sub-authorityName,date:specific
	This was actually my initial proposal to the tag: URI authors. While
it would satisfy the relevant requirements, it has a number of negative
points.
	1. This would require a modification to the current, relatively
stable Internet Draft which restricts authorityNames to domain names and
email addresses. I believe that, without compelling reasons, it is best to
seek backwards compatibility with the existing specifications and common
usage. tag: URI parsers currently exist. We shouldn't risk breaking them
without a compelling reason.
	2. The proposal would increase implementation complexity slightly by
requiring special handling an potentially % encoding of the character "," if
it appears in a sub-authorityName. On the other hand, if sub-authorityName
is a prefix on the "specific" field, the only %encoding requirement would be
for ":" (since it is the proposed terminator of the sub-authorityName).
(Note: This means that in some very rare cases, the "prefix on specific"
approach is likely to be slightly more byte-efficient then the proposed
alternative.)	
	3. If the "/" separator was used, it would be seen by many to import
the http: syntax into a field whose contents is defined by the domain name
specification. Thus, there is risk that users might tend to assume that any
http defined syntax was valid and potentially meaningful. i.e. query
strings, fragments, etc. These assumptions might cause unanticipated
problems. 
	4. By being explicitly recognized in the specification, with
inevitable examples of syntax, etc. it tends to detract from the ability of
authorityName owners to define their own means of assigning
sub-authorityNames.

	Given these negatives and given that there is slightly less
byte-efficiency in the suggested alternative, I would prefer to stick to the
original proposal which has sub-authorityName as a prefix to the "specific"
field. i.e. 
         tag:authorityName,date:sub-authorityName:specific
	This provides a cheap, easily understood and easily implemented
method of generating ids that when properly used are globally unique over
all time and do not rely on scarce resources that are unreasonably difficult
to obtain.

		bob wyman

---

From: Sam Ruby <[email-masked]>
Date: Mon, 06 Sep 2004 10:11:54 -0400

> without a compelling reason.

"Future standards efforts may allow use of other authority names 
following syntax that is disjoint from this syntax. To allow for such 
developments, software that processes tags MUST NOT reject them on the 
grounds that they are outside the syntax for authorityName defined above."

I can also turn that around.  If people are already using colon 
characters in their "specifics", then this could be misinterpreted as a 
sub-authorityName.

> approach is likely to be slightly more byte-efficient then the proposed

Rare, but true.  In fact, can you think of a single example?

> strings, fragments, etc. These assumptions might cause unanticipated

It is meant to conote the "path" portion of the URI - which a number of 
schemes support:

http://www.gbiv.com/protocols/uri/rev-2002/draft-fielding-uri-rfc2396bis-03.html#path

> authorityName owners to define their own means of assigning

I don't follow how "/" followed by a string you define in the given 
position is any more specific than a ":' followed a string you define in 
a different position.

- Sam Ruby

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 6 Sep 2004 13:51:35 -0400

Sam Ruby wrote:
> following syntax that is disjoint from this syntax. To allow for
> such developments, software that processes tags MUST NOT reject
> them on the grounds that they are outside the syntax for 
> authorityName defined above."
	An excellent point! If people are, in fact, following the
specification, then using an authorityName like "pubsub.com/user/bob" should
not, in fact, cause any problems.
	I would *much* prefer a definition of tag: URI that said that in
addition to domain name and email address, an authority name could be
constructed by combining HTTP's domain and path elements. This was my first
proposal to the tag: URI folk... The added complexity of my current proposal
was intended only as a straw-man to see if we could come up with a solution
without making a material change to the current tag: URI draft. However,
given that, as Sam points out, the draft does seem to allow extension of the
list of valid authorityNames by other standards, perhaps, we can simply have
Atom declare that authorityNames derived from HTTP URIs *can* be used in
tag: URI's used to define atom:ids.

> If people are already using colon characters in their "specifics",
> then this could be misinterpreted as a sub-authorityName.
	My assumption is that "specific" should be treated as an opaque
string by all except those who generate it or who are in the closed and
small community of those who know the details of how a particular authority
assigns specifics. Given this, I think it is reasonable to assume that
authorities whose specifics assigning mechanisms would be broken by the ":"
would create alternative, local mechanisms for assigning sub-authorityNames.

>>in some very rare cases, the "prefix on specific" approach is likely 
>>to be slightly more byte-efficient then the proposed alternative.)	
	No.

> position is any more specific than a ":' followed a string you define in 
	The difference I mentioned was not a technical one but rather a
psychological one. And, I'll admit that I was probably suggesting a point
much to fine for this discussion.

		bob wyman