Re: [Uri-review] Last Call: <draft-holsten-about-uri-scheme-06.txt> (The 'about' URI scheme) to Proposed Standard

[Mykyta Yevstifeyev <[e-mail]>]

Hello,

The authors of draft-holsten-about-uri-scheme kindly allowed me to 
co-edit this document to resolve received LC comments.  After some 
internal discussions we decided to request community feedback on 
proposed changes to the draft.  The LC comments can be found at IETF 
discussion mailing list archive 
(http://www.ietf.org/mail-archive/web/ietf/current/maillist.html), 
entitled "Re: Last Call: <draft-holsten-about-uri-scheme-06.txt> (The 
'about' URI scheme) to Proposed Standard".

Three most significant changes are listed below.  So, please feel free 
to express your opinion on them.

==========
First of all, the Introduction section was completely rewritten; now it 
reads:

> 1.  Introduction
>
>    This document specifies the 'about' URI scheme, that may be used by
>    the applications for almost any desired purpose, such as providing
>    access to application information, settings, preferences, and even so
>    called "Easter eggs" (i. e. intentional hidden message, in-joke or
>    feature in the application; see [EASTER-EGGS]).  It does not put any
>    limit on the type of the information, it designates the access to.
>
>    While any number of existing schemes could be used to identify such
>    resources, 'about' URI has become the de facto standard.  The 'about'
>    URI scheme has been used by many applications for quite a long time
>    informally.  They include Microsoft Internet Explorer, Mozilla
>    Firefox, Safari, Google Chrome, Konqueror and many others.  However
>    during this time the 'about' URI scheme have not been given any
>    specification, either published as RFC or in any other way.  This
>    document is to remove such uncertainty and give this scheme an
>    official specification and registration.  It also established the
>    IANA registry for reserved 'about' URIs segment tokens.
==========
The next change is improved Section 5, to make more clear description of 
issues, covered by it.  Now it is:

> 5.  Resolving 'about' URIs
>
>    All 'about' URIs are categorized in three ways:
>
>    o Reservation.  A reserved 'about' URI is one that is claimed and
>      defined by a specification for use in a specific context.
>
>    o Resolution.  Reserved 'about' URIs MAY be defined as resolvable,
>      meaning that they resolve to a defined resource, even outside of
>      their defined usage context.
>
>    o Recognition.  This relates to whether or not a given application
>      recognizes a given URI and knows how to resolve it to a particular
>      resource.
>
>    The division of 'about' URIs into the reservation and resolution
>    categories is per-fact while the recognition per-application.
>    Therefore, while an 'about' URI may be classified as, for example,
>    reserved and resolvable, it may be not be recognized by all
>    applications.
>
> 5.1.  Reservation
>
>    A reserved 'about' URI is one that is claimed and defined by a
>    specification for use in a specific context.  A reserved 'about' URI
>    can be defined as either resolvable or unresolvable.
>
>    An unreserved 'about' URI is any other 'about' URI that is not
>    defined by a specification for use in a specific context, but which
>    MAY be recognized by an application.
>
> 5.1.1.  about:blank
>
>    The 'about' URI with the segment equal to "blank" and no query
>    component is reserved by this specification as resolvable. i.e.
>    "about:blank".  Applications resolving the URI "about:blank" MUST
>    return a resource representing blank page.  This specifications does
>    not put any limitations on the contents of such resource, but it
>    recommends it SHOULD be a resource of zero length, containing no
>    data, with the text/html media type [RFC2854] and the UTF-8 character
>    encoding [RFC3629].
>
>    Note: If a query component is provided with "about:blank", such as
>    "about:blank?" or "about:blank?foo", then the URI is not considered
>    to be reserved by this specification.
>
> 5.2.  Resolution
>
>    A reserved 'about' URI defined as resolvable means that a conforming
>    implementation must resolve the given URI as defined in any context.
>
>    For example, if a web browser recognizes a reserved and resolvable
>    URI, and a user enters that URI into the address bar, the web browser
>    would resolve the URI and return the resource to the user, as defined
>    by the specification that reserved it.
>
>    A reserved 'about' URI defined as unresolvable means that there is no
>    defined resolution process for the URI that applies outside of the
>    specific context for which it is reserved.  An implementation MAY
>    attempt to resolve the URI in an implementation-specific manner.
>
>    For example, the "about:legacy-compat" URI that is reserved by HTML
>    [HTML] for use in a legacy-parser compatible HTML DOCTYPE is defined
>    as unresolvable.  If a user enters it into the address bar of their
>    browser, the browser MAY return any implementation-specific resource.
>
> 5.3.  Recognition
>
>    A recognized 'about' URI is an 'about' URI that recognized by an
>    application.  Applications that recognize reserved and resolvable
>    URIs MUST use the defined resolution process.  Applications that
>    recognize unreserved or unresolvable URIs MAY resolve the URI in an
>    implementation-specific manner.
>
>    Applications MAY recognize and resolve any unreserved 'about' URI, or
>    any reserved but unresolvable 'about' URI used outside of its defined
>    context, to any resource, either internal or external, or redirect to
>    an alternative URI.
>
>    An unrecognized 'about' URI is an 'about' URI that is not recognized
>    by an application.  Applications SHOULD resolve unrecognized 'about'
>    URIs in the same way as "about:blank".
>
>    Note: As 'about' URIs are designed to be internal to each
>    application, there is no expectation of any unreserved or
>    unresolvable URI returning the same resource among different
>    applications.  However, it is worth noting that some conventions have
>    arisen for providing particular functionality via common 'about'
>    URIs.
>
>    Historical note: Early versions of Netscape and Microsoft Internet
>    Explorer resolved unreserved 'about' URIs in the following way: they
>    just displayed the text after "about:", treating it as HTML document.
>    However currently these applications refused such behavior; actually
>    it is deprecated.

==========
The third significant change is addition of regulations regarding the 
registry for reserved about URI segment tokens.  The full text is as 
follows:

> 9.2. IANA Registry for Reserved 'about' URIs Segment Tokens
>
>    IANA is asked to create and maintain the registry called "Reserved
>    'about' URIs Segment Tokens" following the guidelines below.
>
>    The registry's entries consist of 1 field, called "Reserved 'about'
>    URI Segment Token".  The reserved 'about' URI segment token refers to
>    the string used in the <segment> part of 'about' URIs, with the
>    syntax described in Appendix A of RFC 3986 [RFC3986] for the
> <segment> rule.  The entries in the registry MUST refer only to
>    reserved 'about' URIs, as described in Section 5.1.
>
>    The registration procedures for this registry are 'First Come First
>    Served', described in RFC 5226 [RFC5226].  The registrant of such
>    token SHALL also provide the following registration template, that
>    SHALL be available on IANA web site:
>
>    o Reserved 'about' URI Segment Token.  REQUIRED field.  Desired
>      'about' URI token, compliant to the syntax described in Appendix A
>      of RFC 3986 [RFC3986] for the <segment> rule
>
>    o Intended Usage.  REQUIRED field.  A short description of intended
>      usage of 'about' URI with such segment token
>
>    o Resolvable 'about' URI.  REQUIRED field.  Should be "yes" if
>      resolvable or "no" if unresolvable, per Section 5.2 of this
>      document
>
>      o Specification.  OPTIONAL field.  References to the document(s),
>      if any, that described the registered 'about' URI
>
>    o Assignment Notes.  OPTIONAL field.  Any additional information
>      about the assignment
>
>    o Contact/Change Controller.  REQUIRED field.  A person or an
>      organization, authorized to change this registration, that should
>      be contacted for further information on the registered 'about'
>      URI,with their contact points
>
>    The registry initially contains the only one registration:
>
>    o 'about' URI segment token:  blank
>
>      Intended usage:  The "about:blank" URI returns the blank page
>
>      Resolvable 'about' URI:  Yes
>
>      Specification:  RFC XXXX (this document - note to RFC Editor)
>
>      Author/Change Controller:  W3C <[e-mail]>

============
The edited version also involves many editorial changes and 
clarifications, except from the most significant, mentioned above.

Once more, feel free to comment these changes and/or express your 
support/objections to them.  Also, when responding, please keep all 
addresses in the message header.

All the best,
Mykyta Yevstifeyev