Re: TAG scheme - some comments

Hi Tony,

Thanks for the feedback. In response:

Hammond, Tony wrote:
> Below some comments (#5 especially) on the TAG draft:
> 
> 	http://www.ietf.org/internet-drafts/draft-kindberg-tag-uri-06.txt
> 
> Cheers,
> 
> Tony
> 
> 
> 1. Was going to critique Sect. 1.1
> 
> 	'Identifiers ... come from a practically inexhaustible supply'
> 
> and then realized that 'specific' component can be used to realize any level
> of granularity. I do wonder though (apart from simplicity of course) why
> only dates are suupported in the 'taggingEntity' and not datetimes. Of
> course, a time element could be tucked away in the 'specific' component, but
> would it not make more sense to be able to expose it publicly? I am thinking
> that production systems may want this level of granularity. There's a big
> difference in hiding a time element within the user 'specific' component and
> exposing it to a TAG processor.

We've been over that point several times. For me, the arguments for 
sticking with a granularity of a day are: (a) simplicity, (b) potential 
issues with verifying assignment at a granularity of less than a day, 
and (c) redundancy -- there *isn't* a "big difference" between using the 
'specific' component and the 'taggingAuthority' component, as far as a 
given tagging entity is concerned.  You might have a point if 
taggingAuthority had a significance beyond the simple ability to mint 
tags; but it doesn't.

> 
> 2. Sect 1.d - presumably the wording 'electronic resource' would better read
> 'electronic representation' or somesuch, otherwise 'resource' is being used
> in a different sense from that in formal URI usage.

I don't understand your point here. The draft refers to "an electronic 
resource accessible via a default resolution mechanism" -- and that's 
within accepted usage, AFAIK. E.g. 2396bis says:
'Given a URI, a system may attempt to perform a variety of operations on 
the resource, as might be characterized by such words as *"access"*, 
"update", "replace", or "find attributes".' (my emphasis)

> 
> 3. Para on URLs and following first bullet. Better to use URI exclusively?
> E.g. one could change wording
> 
> 	"URLs (in particular, "http" URLs) are sometimes..."
> 
> to something like
> 
> 	"Many URI schemes (in particular, "http") are sometimes..."
> 
> etc.

Good point.

> 
> 4. The syntax as laid out in the BNF would appear to reject the possibility
> of fragments. Is that the case? Note that -2396bis-07 includes the fragment
> component within the URI production - differently from RFC2396.
> 
> 	
> http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-07.txt
> 
> Also note that the 'specific' comonent allows for '?', i.e. TAG thus allows
> for querystrings. Is that the intention?

2396bis has changed things under our feet but at any rate I think I've 
been inconsistent. To be clear: I can't think of a reason to disallow 
fragments or query components for tags.

But now I'm confused as to what tag -- and any other URI scheme -- is 
supposed to do about queries and fragments -- parrot the query and 
fragment syntax from 2396bis?! (That's a question for anyone who might 
be reading, BTW.)

> 
> 5. Sect 2.1 (para "Authority names...") and Sect. 4 ("There is a significant
> possibility...").
> 
> I do not see how one can issue a syntax and then require TAG processors to
> ignore that syntax in order to futureproof the spec. That is the statements
> 
> 	"To allow for such developments, software that processes tags MUST
> NOT reject them on the grounds that they are outside the syntax for
> authorityNamde defined above."
> 
> 	"As stated in Section 2, however, to allow for future expansion,
> software MUST NOT reject tags which do not conform to the syntax specified
> in Section 2."
> 
> IMO would appear to invalidate the utility of the spec. The way to deal with
> this situation is presumably to reissue a new TAG spec at such time as TAG
> processors have widespread support for alternative authority names.
> 

You make me realise that the second quote from the draft is too loose: 
the draft's true position is that authorityName might allow new forms, 
but not the rest of the tag syntax.

But I'm not wedded to this idea and wouldn't feel strongly against 
removing it from the draft. I'd like to hear what others think.

> 6. Note that normalization issues are ducked. :) Probably wisely too. Not
> sure what the ramifications of this might be especially wrt TAG processors
> and %-encoding.

Yes, we decided that tags that are different as strings (with same 
character encoding) are different, full stop. It's nice and easy to 
understand and there's no compelling need for a more sophisticated 
criterion for equality.

> 
> 7. Should be rationalized throughout: pct-encoded <> percent-encoded.
> 2396bis-07 uses 'percent-encoded' in the text and 'pct-encoded' as the
> production rule. 

Indeed, there are a few places where I used 'pct-encoded' when I should 
have used 'percent-encoded'.

Thanks again.

Cheers,

Tim.

-- 

Tim Kindberg
hewlett-packard laboratories
filton road
stoke gifford
bristol bs34 8qz
uk

purl.org/net/TimKindberg
timothy@hpl.hp.com
voice +44 (0)117 312 9920
fax +44 (0)117 312 8003

Received on Friday, 22 October 2004 10:04:50 UTC