W3C home > Mailing lists > Public > uri@w3.org > October 2004

RE: draft-kindberg-tag-uri

From: Tim Kindberg <timothy@hpl.hp.com>
Date: Tue, 19 Oct 2004 13:35:49 +0100
To: <uri@w3.org>
Cc: "'Sandro Hawke'" <sandro@w3.org>, "'Martin Duerst'" <duerst@w3.org>, <hardie@qualcomm.com>, "'Tim Kindberg'" <timothy@hpl.hp.com>
Message-Id: <20041019123602.D556727117@mailhub.hp.com>

Following Martin Duerst's helpful comments (below), I've produced a new
draft of "tag" and submitted it as an Internet-Draft
(draft-kindberg-tag-uri-06). There's a delay in I-D processing at the
moment, so in the meantime it can be found at http://taguri.org/06/ .

The update consists mainly of changes relating to "Internationalization"*.
I've also made some minor textual improvements & additions. As usual, all
comments are welcome.

Cheers,

Tim.

*"Getting internationalisation right" consisted of balancing, on the one
hand, the requirement to avoid minting tag URIs/IRIs with percent-encoded
characters -- in the interests of human-friendliness; and, on the other
hand, the requirement to include percent-encoded characters in the syntax
nonetheless: (a) to make it possible to verify the conformance of tag IRIs
and (b) to provide a way for software that handles URIs but not IRIs to
handle tags, albeit with some consequent issues.


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
  

> -----Original Message-----
> From: Martin Duerst [mailto:duerst@w3.org] 
> Sent: 30 August 2004 10:18
> To: Tim Kindberg
> Cc: uri@w3.org; Sandro Hawke
> Subject: draft-kindberg-tag-uri
> 
> Hello Tim,
> 
> Finally I get around to comment on the newest version of your 
> TAG draft, a pre-draft at 
> http://taguri.org/06/draft-kindberg-tag-uri-06.txt.
> 
> The main comment is that you try to have two separate 
> definitions, one for TAG URIs and the other for TAG IRIs, but 
> that isn't how the URI spec and the IRI spec work. For 
> further background, please also see the issue and discussion at
> http://www.w3.org/International/iri-edit#iri-scheme-38
> 
> I also give some comments on general issues that I found, 
> mostly editorial.
> 
> 
> At 13:27 04/08/24 +0900, Martin Duerst wrote:
> >Network Working Group                                        
> T. Kindberg
> >Internet-Draft                               Hewlett-Packard 
> Corporation
> >Expires: January 27, 2005                                    
>    S. Hawke
> >                                                World Wide 
> Web Consortium
> >                                                            July 29, 
> >2004
> >
> >
> >                           The 'tag' URI scheme
> >                        draft-kindberg-tag-uri-06
> 
> [snip] [also snipped all page breaks]
> 
> >Abstract
> >
> >    This document describes the "tag" Uniform Resource 
> Identifier (URI)
> >    scheme,
> 
> This comma is somewhat confusing. It's probably best to end 
> the sentence here and integrate the points in the remaining 
> clause into the rest of the paragraph.
> 
> 
> >for identifiers that are unique across space and time.  Tag
> >    URIs (also known as "tags") are distinct from most other 
> URIs in that
> >    there is no authoritative resolution mechanism.  A tag 
> may be used
> >    purely as an entity identifier.  Unlike UUIDs or GUIDs
> 
> Abbreviations shouldn't appear without expansion. (see RFC 
> guidelines) Also, there should be references for these terms, 
> but referencing doesn't fit well into an abstract. I'd 
> concentrate on the description of tags themselves in the 
> abstract, in positive terms (what tags do, not what they 
> don't), and put comparision with other schemes into a section 
> in the body of the document, with references.
> 
> 
> >such as "uuid"
> 
> So the uuid scheme is an UUID? Or a GUID? Or both? Some 
> readers will be confused by such minor term differences 
> without clear explanation.
> 
> 
> >    URIs and "urn:oid" URIs, tags are designed to be 
> tractable to humans.
> >
> >    Furthermore, using tags has some advantages over the 
> common practice
> >    of using "http" URIs as identifiers for non-HTTP-accessible
> >    resources.
> 
> [snip]
> 
> 
> >1.  Introduction
> >
> >    A tag is a type of Uniform Resource Identifier (URI) [1] 
> designed to
> >    meet the following requirements:
> >
> >    1.  Identifiers are likely to be unique across space and time,
> 
> How likely? Very likely? Designed to make it easy to be?
> 
> 
> >and
> >        come from a practically inexhaustible supply.
> >    2.  Identifiers are relatively convenient for humans to mint
> >        (create), read, type, remember etc.
> >    3.  No registration is necessary,
> 
> -> no central registration is necessary
> 
> 
> >at least for holders of domain
> >        names or email addresses;
> 
> I think that each such holder who creates tags has to keep 
> their own registry to avoid local conflicts. The draft should 
> be quite a bit more explicit about this.
> 
> 
> >and there is negligible cost to mint
> >        each new identifier.
> >    4.  The identifiers are independent of any particular resolution
> >        scheme.
> >
> >    For example, the above requirements may apply in the 
> case of a user
> >    who wants to place identifiers on their documents:
> 
> These are the requirements met by tags, yes? It'd be better 
> to just say so.
> 
> 
> >    a.  They
> 
> Who? The documents? The identifiers? The users? Please rework 
> the whole list so that all the items follow the same 
> syntactic structure.
> 
> 
> >want to be reasonably sure that the identifier is unique.
> >        Global uniqueness is valuable because it prevents identifiers
> >        from becoming unintentionally ambiguous.
> >    b.  It is useful for the identifier to be tractable to humans:
> 
> 'to humans' -> 'by humans'?
> 
> >they
> >        should be able to mint new identifiers conveniently, 
> and to type
> >        them into emails and forms.
> 
> For more aspects of this (memorize,...), see the 'overview 
> and motivation'
> section of IRIs.
> 
> 
> >    c.  They do not want to have to communicate with anyone 
> else in order
> >        to mint identifiers for their documents.
> >    d.  The user wants to avoid identifiers that might be 
> taken to imply
> >        the existence of an electronic resource accessible 
> via a default
> >        resolution mechanism, when no such electronic 
> resource exists.
> >
> >    Existing identification schemes satisfy some but not all of the
> >    general requirements above.
> 
> Why 'general'? I read it as if these requirements would always apply.
> 
> 
> >For example:
> >
> >    UUIDs [8], [9] are hard for humans to read.
> >
> >    OIDs [10], [11] and Digital Object Identifiers [12] 
> require naming
> >    authorities to register themselves,
> 
> 'themselves': If the identifiers register themselves, that 
> would be great. But the problem is that registration requires 
> work by an user.
> 
> 
> >even if they already hold a
> >    domain name registration.
> 
> So 'they' is users, not ids? But users don't register 
> themselves, they register some ids or schemes,...
> 
> 
> >    URLs (in particular, "http" URLs) are sometimes used as 
> identifiers
> >    that satisfy most of our requirements.
> 
> 'our': Who is 'we'? Better avoid.
> 
> 
> >Many users and organisations
> >    have already registered a domain name, and the use of 
> the domain name
> >    to mint identifiers comes at no additional cost.  But there are
> >    drawbacks to URLs-as-identifiers:
> >
> >    o  An attempt may be made to resolve a 
> URL-as-identifier, even though
> >       there is no resource accessible at the "location".
> >    o  Domain names change hands and the new assignee of a 
> domain name
> >       can't be sure that they are minting new names.  For 
> example, if
> >       example.org is assigned first to a user Smith and 
> then to a user
> >       Jones, there is no systematic way for Jones to tell 
> whether Smith
> >       has already used a particular identifier such as http://
> >       example.org/9999.
> >    o  Entities could rely on purl.org
> 
> add: or a similar service.
> Also, use 'http://purl.org' rather than just 'purl.org', or 
> provide a reference.
> 
> 
> >as a (first-come, first-served)
> >       assigner of unique URIs; but a solution without reliance upon
> >       another entity such as the Online Computer Library 
> Center (OCLC,
> >       which runs purl.org) may be preferable.
> >
> >    Lastly, many entities -- especially individuals -- are 
> assignees of
> >    email addresses but not domain names.  It would be preferable to
> >    enable those entities to mint unique identifiers.
> >
> >2.  Tag Syntax and Rules
> >
> >    This section first specifies the syntax of tag URIs and gives
> >    examples.  It then describes a set of rules for minting 
> tags designed
> >    to make them unique.  Finally, it discusses the resolution and
> >    comparison of tags.
> >
> >2.1  Tag Syntax and Examples
> >
> >    The general syntax of a tag URI, in ABNF, is:
> 
> You need a reference to the ABNF RFC
> (http://www.ietf.org/rfc/rfc2234.txt),
> and to check the ABNF with some tool
> (see advice to Internet Draft and RFC authors).
> 
> 
> >       tagURI        = "tag:" taggingEntity ":" [specific]
> 
> Is it possible for 'specific' to be empty? In that case, is 
> the ':' necessary? Is there any specific meaning for this 
> case? If this is allowed, please provide an example.
> Also, later, 'specific' is defined as *(...), so the [] 
> parentheses are not at all necessary.
> 
> 
> >    Where:
> >
> >       taggingEntity = authorityName "," date
> >       authorityName = DNSname / emailAddress
> >       date          = 4dig ["-" 2dig ["-" 2dig ]] ; see ISO8601 [2]
> 
> It would be much clearer if this were:
>         date          = year ["-" month ["-" day ]] ; see ISO8601 [2]
> and then
>         year          = 4*DIGIT
>         month         = "01" / "02" / "03" / ...
>         day           = ("0" %x31-39) / (("1" / "2") DIGIT) / 
> "30" / "31"
> or some such. This easily catches a lot of illegal stuff, and 
> makes the semantics much more obvious.
> 
> 
> >       DNSname       = DNScomp / DNSname "." DNScomp  ; see 
> RFC1035 [3]
> 
> It's much better to write this rule in a non-recursive fashion:
> 
>         DNSname       = DNScomp *( "." DNScomp )
> 
> And you better don't cite RFC 1035 directly.
> 
> 
> >       DNScomp       = alphaNum [*(alphaNum /"-") alphaNum]
> 
> To allow Internationalized Domain Names, you have to add 
> pct-encoded here:
> 
>         DNScomp       = dnsChar [*(dnsChar / "-") dnsChar]
>         dnsChar       = alphaNum / pct-encoded
> 
> 
> >       emailAddress  = 1*(alphaNum /"-"/"."/"_") "@" DNSname
> 
> I'd strongly recommend to also add pct-encoded here, making 
> this future-proof for potential internationalization of the LHS:
> 
>         emailAddress  = 1*(alphaNum /"-"/"."/"_"/pct-encoded) 
> "@" DNSname
> 
> 
> >       alphaNum      = DIGIT / ALPHA
> >       specific      = *( pchar / "/" / "?" ) ; pchar from 
> RFCXXXX [1]
> 
> pchar includes pct-encoded, so this is okay in terms of basic syntax.
> 
> 
> >       ALPHA         = %x41-5A / %x61-7A ; any char in the 
> range "A"-"Z"
> >       or "a"-"z"
> >       DIGIT         = %x30-39 ; any char in the range "0" 
> through "9"
> 
> Just import ALPHA and DIGIT from the ABNF RFC, don't repeat them here.
> 
> 
> At this point, you should say some general things about pct-encoded.
> What you want to say probably is:
> - pct-encoded (including in the case of pchar) is only allowed for
>    octets above %7F.
> - pct-encoded (including in the case of pchar) is only allowed in
>    sequences that are valid UTF-8 octet sequences.
> - pct-encoded is used to encode characters using UTF-8.
> - There may be additional restrictions for each of the components
>    allowing pct-encoded.
> - That pct-encoded is only allowed to allow the minting of tag IRIs,
>    but that tags created as URIs from the start should/must never
>    contain any pct-encoded pieces, and that tag IRIs also should/must
>    never contain any pct-encoded pieces.
> 
> >    The component "taggingEntity" is the name space part of 
> the URI.  To
> >    avoid ambiguity, the domain name in "authorityName" 
> (whether an email
> >    address or a simple domain name) MUST be fully qualified.  It is
> >    RECOMMENDED that the domain name should be in lowercase form.
> >    Alternative formulations of the same authority name will 
> be counted
> >    as distinct
> 
> 'counted' -> 'treated', or even better just say that these 
> *are* different tags.
> 
> 
> >and hence tags containing them will be unequal (see
> >    Section 2.4).  For example, tags beginning "tag:HP.com,2000:" are
> >    never equal to those beginning "tag:hp.com,2000:", even 
> though they
> >    refer to the same domain name.
> >
> >    Authority names could, in principle, belong to any syntactically
> >    distinct namespaces whose names are assigned to a unique 
> entity at a
> >    time.  Those include, for example, certain IP addresses, 
> certain MAC
> >    addresses, and telephone numbers.  However, to simplify the tag
> >    scheme, we restrict authority names to be domain names and email
> >    addresses.  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.
> 
> Here, say that a DNSName must, after decoding of 
> percent-encoding and interpretation of the resulting octet 
> sequence as UTF-8, be an Internationalized Domain Name 
> according to IDNA [RFC 3490].
> You may also want to say that a DNSName, after decoding of 
> percent-encoding and interpretation of the resulting octet 
> sequence as UTF-8, should be normalized as defined by 
> Nameprep [RFC 3491] to avoid producing TAGs that look very 
> similar but are not the same.
> 
> Also, say that pct-encoded is allowed on the left hand side 
> of emailAddress (before the "@") for future-compatibility, 
> and is only to be used if and when there is an IETF 
> Standards-Track document specifying how internationalized 
> email address left hand sides are handled.
> 
> 
> >    The component "specific" is the name-space-specific part 
> of the URI:
> >    it is a string of URI characters (see restrictions in syntax
> >    specification) chosen by the minter of the URI.  It is 
> RECOMMENDED
> >    that specific identifiers should be human-friendly.
> 
> Add some text here that after decoding of percent-encoding 
> and interpretation of the resulting octet sequence as UTF-8, 
> "specific" should be in NFC and preferably even in NFKC.
> 
> 
> >    Examples of tag URIs are:
> >
> >       tag:timothy@hpl.hp.com,2001:web/externalHome
> >       tag:sandro@w3.org,2004-05:Sandro
> >       
> tag:my-ids.com,2001-09-15:TimKindberg:presentations:UBath2004-05-19
> >       tag:blogger.com,1999:blog-555
> >       tag:yaml.org,2002:int
> 
> An example without 'specific', and some I18N examples, should 
> be added (I can help).
> 
> 
> >2.2  Rules for Minting Tags
> >
> >    As Section 2.1 has specified, each tag consists of a 
> "tagging entity"
> >    followed, optionally, by a specific identifier.  The 
> tagging entity
> >    is designated by an "authority name" -- a fully 
> qualified domain name
> >    or an email address containing a fully qualified domain name --
> >    followed by a date.  The date is chosen to make the 
> tagging entity
> >    globally unique, exploiting the fact that domain names and email
> >    addresses are assigned to at most one entity at a time.  
> That entity
> >    then ensures that it mints unique identifiers.
> 
> The following paragraph can be reworded (and probably 
> simplified) once the chances to the syntax rules have been made.
> 
> >    The date specifies, according to the Gregorian calendar 
> and UTC, any
> >    particular day on which the authority name was assigned to the
> >    tagging entity at 00:00 UTC (the start of the day).  The 
> date MAY be
> >    a past or present date on which the authority name was 
> assigned at
> >    that moment.  The date is specified using one of the "YYYY",
> >    "YYYY-MM" and "YYYY-MM-DD" formats allowed by the ISO 
> 8601 standard
> >    [2].  The tag specification permits no other formats.  Tagging
> >    entities MUST ascertain the date with sufficient accuracy
> >    to avoid accidentally using a date on which the 
> authority name was
> >    not in fact assigned (many computers and mobile devices 
> have poorly
> >    synchronised clocks).  The date MUST be reckoned from 
> UTC -- which
> >    may differ from the date in the tagging entity's local 
> timezone at
> >    00:00 UTC.
> 
> I think some readers may be confused by "reckoned from UTC". 
> Why not just say that the date is always in UTC?
> 
> 
> 
> >That distinction can generally be safely ignored in
> >    practice, but not on the day of the authority name's 
> assignment.  In
> >    principle it would otherwise be possible on that day for 
> the previous
> >    assignee and the new assignee to use the same date and 
> thus mint the
> >    same tags.
> >
> >    In the interests of brevity, the month and day default 
> to 01.  A day
> >    value of 01 MAY be omitted; a month value of 01 MAY be 
> omitted unless
> >    it is followed by a day value other than 01.
> 
> I'd quote all the 01 (i.e. "01") for easier readability. It 
> is easy here to confuse MAY with the month of May.
> 
> 
> >For example, "2001-07"
> >    is the date 2001-07-01 and "2000" is the date 
> 2000-01-01.  All date
> >    formulations specify a moment (00:00 UTC) of a single 
> day, and not a
> >    period of a day or more such as "the whole of July 2001" or "the
> >    whole of 2000".  Assignment at that moment is all that 
> is required to
> >    use a given date formulation.
> 
> formulation -> format? or just 'use a given date'?
> 
> 
> >    Tagging entities should be aware that alternative 
> formulations of the
> >    same date will be counted as distinct and hence tags 
> containing them
> >    will be unequal.  For example, tags beginning 
> "tag:hp.com,2000:" are
> >    never equal to those beginning "tag:hp.com,2000-01-01:", 
> even though
> >    they refer to the same date (see Section 2.4).
> 
> Here and elsewhere: The IETF prefers to use domain names such 
> as example.com.
> 
> 
> >    An entity MUST NOT mint tags under an authority name that was
> >    assigned to a different entity at 00:00 UTC on the given 
> date, and it
> >    MUST NOT mint tags under a future date.
> >
> >    An entity that acquires an authority name immediately 
> after a period
> >    during which the name was unassigned MAY mint tags as if 
> the entity
> >    was assigned the name during the unassigned period.  
> This practice
> >    has considerable potential for error and MUST NOT be 
> used unless the
> >    entity has substantial evidence that the name was 
> unassigned during
> >    that period.  The authors are currently unaware of any 
> mechanism that
> >    would count as evidence, other than daily polling of the "whois"
> >    registry.
> >
> >    For example, Hewlett-Packard holds the domain 
> registration for hp.com
> >    and may mint any tags rooted at that name with a current 
> or past date
> >    when it held the registration.  It must not mint tags such as
> >    "tag:champignon.net,2001:" under domain names not 
> registered to it.
> >    It must not mint tags dated in the future, such as
> >    "tag:hp.com,2999:".  If it obtains assignment of
> >    "extremelyunlikelytobeassigned.org" on 2001-05-01, then 
> it must not
> >    mint tags under 
> "extremelyunlikelytobeassigned.org,2001-04-01" unless
> >    it has evidence proving that that name was continuously 
> unassigned
> >    between 2001-04-01 and 2001-05-01.
> >
> >    A tagging entity mints specific identifiers that are 
> unique within
> >    its context, in accordance with any internal scheme that 
> uses only
> >    URI characters.  Some tagging entities (e.g.  
> corporations, mailing
> >    lists) consist of many people, in which case group 
> decision-making
> >    and record-keeping procedures SHOULD be used to achieve 
> uniqueness.
> 
> Record-keeping is important for individuals, too.
> 
> 
> >2.3  Resolution of Tags
> >
> >    There is no authoritative resolution mechanism for tags. 
>  Unlike most
> >    other URIs, tags can only be used as identifiers, and are not
> >    designed to support resolution.  If authoritative resolution is a
> >    desired feature, a different URI scheme should be used.
> >
> >2.4  Equality of Tags
> >
> >    Tags are simply strings of characters and are considered 
> equal if and
> >    only if they are completely indistinguishable in their machine
> >    representations.  That is, one can compare tags for equality by
> >    comparing the numeric codes of their characters, in sequence, for
> >    numeric equality.  This equality-criterion allows for 
> > simplification
> 
> equality-criterion -> equality criterion
> 
> 
> >    of tag-handling software, which does not have to 
> transform tags in
> >    any way to compare them.
> 
> 
> >3.  Internationalisation
> >
> >    So far, we have considered tags as URIs, which are 
> represented in a
> >    subset of US-ASCII characters.  As befits our requirement for
> >    identifiers to be tractable to humans, tags can also be minted as
> 
> The 'can also be minted as' probably needs some more explanation.
> In general, any uri scheme that allows pct-encoded in the 
> right way can also be used with IRIs. See below.
> 
> 
> >    Internationalized Resource Identifiers (IRIs) [4].  That 
> is, they can
> >    be minted in languages that use any characters from the Universal
> >    Character Set.
> 
> Does a tag have a language? I think it's better to just say:
> they can be minted using any characters from ...
> 
> 
> The following procedure can probably be removed. If not, the 
> following details should be fixed:
> 
> >    The procedure for minting tags as IRIs is to use the 
> specification of
> >    Section 2 but with the following syntactic changes:
> >    o  An International Domain Name (IDN) [5] represented 
> according to
> >       the rules of 'nameprep' [6] may be used in place of a 
> domain name
> >       in authorityName.  That includes a domain name 
> appearing on the
> >       right-hand side of an email address.
> >    o  If a standard arises for expressing email addresses in
> >       international form -- that is, including the left-hand side of
> >       email addresses -- then that form will be allowed in
> >       authorityName.
> >    o  An international authorityName MUST appear in at 
> least Normalized
> >       Form C (NFC) and SHOULD appear in Normalized Form KC 
> (NFKC) [7].
> 
> This should not be necessary, because Nameprep takes care of this.
> But it may be a good thing to say for 'specific'.
> 
> 
> >    o  The specific component of a tag IRI may be any string 
> allowed by
> >       the ABNF term *( ipchar / "/" / "?" ) defined in [4].
> 
> I recommend adding some normalization restrictions here, for 
> the benefit of transcribability,...
> 
> >    Two tag IRIs are equal if and only if they are identical 
> as character
> >    sequences -- and thus that their machine representations are
> >    identical when using the same character encodings.
> 
> It may be a good idea to repeat here explicitly that:
> - The use of pct-encoding in the syntax rules is only allowed in
>    order to define the syntax of IRIs allowed in the tag scheme.
> - pct-encoding should not be used in tags generated using only
>    US-ASCII characters.
> - pct-encoding should not be used in tags generated including
>    non-ASCII characters (i.e. IRIs).
> - A tag IRI is not equivalent to the tag URI resulting after
>    mapping the IRI to an URI according to Section 3.1 of [IRI].
>    To reduce any problems resulting from this:
>    - tags should be used mainly with technology that can transport and
>      handle IRIs (such as RDF).
>    - If tags are temporarily converted to URIs because they have
>      to be passed to some infrastructure that isn't able to handle
>      IRIs, they should be converted back to IRIs when being recived
>      back from that infrastructure.
> 
> 
> 
> >4.  Security Considerations
> >
> >    Minting a tag, by itself, is an operation internal to the tagging
> >    entity with no external consequences.  The consequences 
> of using an
> >    improperly minted tag (due to malice or error) in an application
> >    depends on the application, and must be considered in 
> the design of
> >    any application that uses tags.
> >
> >    There is a significant possibility of minting errors by 
> people who
> >    fail to apply the rules governing dates, or who use a shared
> >    (organizational) authority-name without prior organization-wide
> >    agreement.  Tag-aware software MAY help catch and warn 
> against these
> >    errors.  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.
> >
> >    A malicious party could make it appear that the same 
> domain name or
> >    email address was assigned to each of two or more 
> entities.  Tagging
> >    entities SHOULD use reputable assigning authorities, and verify
> >    assignment wherever possible.
> >
> >    Entities SHOULD also avoid the potential for malicious 
> exploitation
> >    of clock skew, by using authority names that were assigned
> >    continuously from well before to well after 00:00 UTC on the date
> >    chosen for the tagging entity -- preferably by intervals 
> in the order
> >    of days.
> >
> >5.  References
> >
> >5.1  Normative References
> >
> >    [1]  Berners-Lee, T., Fielding, R. and L. Masinter, 
> "Uniform Resource
> >         Identifier (URI): Generic Syntax (Note to the RFC 
> Editor: Please
> >         update this reference with the RFC resulting from
> >         draft-fielding-uri-rfc2396bis-xx.txt, and remove 
> this Note)",
> >         draft-fielding-uri-rfc2396bis-06 (work in 
> progress), July 2004.
> >
> >    [2]  "Data elements and interchange formats -- Information
> >         interchange -- Representation of dates and   times", ISO
> >         (International Organization for Standardization) 
> ISO 8601:1988,
> >         1988.
> >
> >    [3]  Mockapetris, P., "Domain names - implementation and
> >         specification", STD 13, RFC 1035, November 1987.
> >
> >    [4]  Duerst, M. and M. Suignard, "Internationalized Resource
> >         Identifiers (IRIs)", draft-duerst-iri-09 (work in progress),
> >         July 2004.
> 
>       This should have a similar RFC Editor comment as [1].
> 
> 
> >    [5]  Faltstrom, P., Hoffman, P. and A. Costello, 
> "Internationalizing
> >         Domain Names in Applications (IDNA)", RFC 3490, March 2003.
> >
> >    [6]  Hoffman, P. and M. Blanchet, "Nameprep: A 
> Stringprep Profile for
> >         Internationalized Domain Names (IDN)", RFC 3491, March 2003.
> >
> >    [7]  Duerst, M. and M. Davis, "Unicode Normalization 
> Forms", Unicode
> >         Standard Annex #15 
> http://www.unicode.org/unicode/reports/tr15/
> >         tr15-23.html, April 2003.
> >
> >5.2  Informative References
> >
> >    [8]   Leach, P. and R. Salz, "UUIDs and GUIDs", 
> draft-leach-uuids-01
> >          (work in progress), 1997.
> >
> >    [9]   "Information technology - Open Systems 
> Interconnection - Remote
> >          Procedure Call (RPC)", ISO (International Organization for
> >          Standardization) ISO/IEC 11578:1996, 1996.
> >
> >    [10]  "Specification of abstract syntax notation one 
> (ASN.1)", ITU-T
> >          recommendation X.208,  (see also RFC 1778), 1988.
> >
> >    [11]  Mealling, M., "A URN Namespace of Object Identifiers", RFC
> >          3061, February 2001.
> >
> >    [12]  Paskin, N., "Information Identifiers", Learned 
> Publishing Vol.
> >          10, No. 2, pp. 135-156,  (see also www.doi.org), 
> April 1997.
> 
> [snip]
> 
> 
> 
> Regards,    Martin.
> 
Received on Tuesday, 19 October 2004 12:36:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:34 GMT