TAG scheme - some comments

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.

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.

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.

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?

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.

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.

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



Tony Hammond

New Technology, Nature Publishing Group
4 Crinan Street, London N1 9XW, UK 

tel:+44-20-7843-4659
mailto:t.hammond@nature.com




********************************************************************************
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
********************************************************************************

Received on Thursday, 21 October 2004 11:32:08 UTC