Second Last Call: <draft-nottingham-http-link-header-10.txt> (Web Linking) to Proposed Standard

[The IESG <[e-mail]>]

The IESG has received a request from an individual submitter to consider
the following document:
- 'Web Linking'
  <draft-nottingham-http-link-header-10.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[e-mail] mailing lists by 2010-10-08. Exceptionally, comments may be
sent to [e-mail] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-nottingham-http-link-header/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-nottingham-http-link-header/

The purpose of this Second Last Call is to confirm some late changes to the IANA procedure/registry.
The following changes are proposed:

In Section 6.2 ("Link Relation Type Registry"), add the 2nd paragraph that reads:

   The underlying registry data (e.g., the XML file) must include
   Simplified BSD License text as described in Section 4.e of the Trust
   Legal Provisions (<http://trustee.ietf.org/license-info>).

In Section 6.2.1 ("Registering New Link Relation Types"), delete the following paragraph:

   When a registration request is successful, the Designated Expert(s)
   will update the registry XML file (using the format described in
   Appendix A including the MIT license) and send it to the
   [e-mail] mailing list (which SHOULD NOT be
   centrally archived, so as to avoid load issues from automated agents,
   and only accept posts from the Designated Expert(s)), so that
   implementers interested in receiving a machine-readable registry can
   do so.  Simultaneously, they will send a text (not XML) version of
   the registry to IANA for publication.

And finally, delete the whole Appendix A (together with A.1, which describes
the Relax NG grammar) which reads:

Appendix A.  Link Relation Registry Format

   To facilitate applications that wish to use registry data in an
   automated fashion, this specification defines an XML-based format for
   the registry entries.

   Each registered relation type is represented by a RelationType
   element, and if any of the app data values are other than the default
   value identified in the Application Data registry, they will be
   represented by appdata elements.

   Note that this format is NOT that in which IANA publishes the
   registry, because doing so would subject IANA's servers to,
   potentially, very high load (e.g., if Web browsers were to
   automatically update their copies of the registry).  Instead, this
   format is published to the [e-mail] mailing
   list, so that interested implementers can subscribe and distribute
   the machine-readable document using their own infrastructure.


No IPR declarations were found that appear related to this I-D.