Uniform Resource Identifier (URI): Generic Syntax
draft-fielding-uri-rfc2396bis-07

[Note]: 'Proposed RFC Editor Note: OLD: URI comparison is performed in respect to some particular purpose,
  and implementations with differing purposes will often be subject to
  differing design trade-offs in regards to how much effort should be
  spent in reducing aliased identifiers. NEW:  URI comparison is performed in respect to some particular purpose,
  and protocols or implementations comparing for purposes will often be subject to
  differing design trade-offs in regards to how much effort should be
  spent in reducing aliased identifiers.' added by Amy Vezza

[Note]: 'Proposed RFC Editor Note: OLD: URI comparison is performed in respect to some particular purpose,
  and implementations with differing purposes will often be subject to
  differing design trade-offs in regards to how much effort should be
  spent in reducing aliased identifiers. NEW:   URI comparison is performed in respect to some particular purpose,
  and protocols or implementations comparing for purposes will often be subject to
  differing design trade-offs in regards to how much effort should be
  spent in reducing aliased identifiers.' added by Amy Vezza

[Note]: 'Proposed RFC Editor Note:

OLD:

URI comparison is performed in respect to some particular purpose,
   and implementations with differing purposes will often be subject to
   differing design trade-offs in regards to how much effort should be
   spent in reducing aliased identifiers.


NEW:

  URI comparison is performed in respect to some particular purpose,
   and protocols or implementations comparing for purposes will often be subject to
   differing design trade-offs in regards to how much effort should be
   spent in reducing aliased identifiers.

' added by Ted Hardie

[Ballot discuss]
Please add a section to the Security Considerations dealing with URI
  as subject alternative names in certificates.  See section 4.2.1.7 of
  RFC 3280.  If a certificate is used to bind a public key to a URI, then
  a user depending on that certificate will have to make a comparison
  between the URI in the certificate and the URI of the resource being
  accessed.  All of the complexity discussed in section 6 of this
  document comes into play.  Guidance is sorely needed.

[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART

His review:

Summary: This document is ready to advance to Full Standard.

If any changes are made to this document before publication, I would
make one suggestion - the Security Considerations section has a
reasonable discussion of "can't assume you can ever reuse this URI",
but doesn't also include "can't ensure this operation is idempotent,
so may be open to inadvertent duplication or malicious replay
attacks". It's not clear whether this goes in a URI document, a URL
document, or something else, so I'll trust the AD's judgement.

[Ballot discuss]
The Heading and the Abstract need to reflect the fact that this document
  obsoletes RFCs 1738, 1808, 2732 and 2396.

  The following three URIs are equivalent:

    http://example.org/~user
    http://example.org/%7euser
    http://example.org/%7Euser

  Following the rules in section 6.2.2.2, a client can determine that they
  are equivalent.  Yet, the last paragraph of section 7.2 indicates that
  such percent-encoded octets must not be decoded before transmission
  across that protocol.  This inconsistency needs to be resolved.

  Please add a section to the Security Considerations dealing with URI
  as subject alternative names in certificates.  See section 4.2.1.7 of
  RFC 3280.  If a certificate is used to bind a public key to a URI, then
  a user depending on that certificate will have to make a comparison
  between the URI in the certificate and the URI of the resource being
  accessed.  All of the complexity discussed in section 6 of this
  document comes into play.  Guidance is sorely needed.

IANA Last Call Comments:
The IANA Considerations section says the following:

  URI scheme names, as defined by  in Section 3.1, form a
  registered name space that is managed by IANA according to the
  procedures defined in [BCP35].

Is this a request for a registration in the following registry?
 
If so, it should state more clearly in the IANA Considerations section
the scheme name to be registered.  Or is this section just pointing out
that there is a registry?

From Roy:

hereby request that an IESG last call be issued for
"draft-fielding-uri-rfc2396bis-06.txt", to be published as an
Internet Standard, obsoleting RFCs 2396, 1808, and 2732, and
updating RFC 1738.

Although not associated with a current working group, the draft has
been developed under the usual procedures of an IETF working group
on the public mailing list of the former URI working group.  A list
of issues that have been addressed by this draft can be found at http://gbiv.com/protocols/uri/rev-2002/issues.html

The mailing list archive is available at

    http://lists.w3.org/Archives/Public/uri/

with work on this revision beginning in July 2002.  The draft has
been edited in XML using the xml2rfc toolset.  The XML version of the
document can be found at

    http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.xml