Opened 11 years ago

Closed 11 years ago

#195 closed protocol enhancement (fixed)

Create registry for rt= and if= values

Reported by: zach@… Owned by: zach@…
Priority: minor Milestone:
Component: link-format Version:
Severity: - Keywords:
Cc:

Description

In Joel Halpern's Gen-Art review it was suggested that we create a registry for the rt= and if= as there is a high possibility for collision when using short strings there.

This ticket is to create registries for values of the rt= and if= attributes.

The registry will be along the lines of the RFC5988 Link Relation Registry. Extension values will be allowed using URIs (and thus the registry value will have similar restrictions as for relations to prevent collision). Expert review will be proposed for registrations.


Change History (3)

comment:1 Changed 11 years ago by zach@…

  • Status changed from new to assigned

The following text is proposed for the registry definition. I would like to propose that expert review is performed on the same link-relations@… mailing list as is used for the Link Relation registry as these are very similar.

7.4.  Registry for Resource Type and Interface Description Values

   This specification establishes two new registries, one for Resource
   Type (rt=) and the other for Interface Description (if=) link target
   attribute values.  This registry is similar to the Link Relation
   Registry defined in [RFC5988].  No initial entries are defined by
   this specification for either registry.

   These registries have the following requirements on values:

   o  Registration values MUST be related to the intended purpose of
      these attributes as described in Section 3.

   o  Registered values MUST conform to the ABNF reg-rel-type definition
      of Section 2, meaning the value MUST start with a lower case
      alphabet character, followed by a sequence of lower case alphabet,
      numeric, "." or "-" characters.  The value MUST NOT contain white
      space.

   o  It is recommended that the period "." character is used for
      dividing name segments, and that the dash "-" character is used
      for making a segment more readable.  Example Interface Description
      values might be "core.batch" and "core.link-batch".

   o  URIs are reserved for free use as extension values for these
      attributes, and MUST NOT be registered.

   Values starting with the characters "core" are reserved, and can only
   be requested for registration when defined in an IETF working group
   document.

   Relation types are registered on the advice of a Designated Expert
   (appointed by the IESG or their delegate), with a Specification
   Required (using terminology from [RFC5226]).

   Registration requests consist of the completed registration template
   below, typically published in an RFC or Open Standard (in the sense
   described by [RFC2026], Section 7).  However, to allow for the
   allocation of values prior to publication, the Designated Expert may
   approve registration once they are satisfied that a specification
   will be published.

   Note that relation types can be registered by third parties, if the
   Designated Expert determines that an unregistered relation type is
   widely deployed and not likely to be registered in a timely manner.

   The registration template for both registries is:

   o  Attribute Value:

   o  Description:

   o  Reference:

   o  Notes: [optional]

   Registration requests should be sent to the (TBD)@ietf.org mailing
   list, marked clearly in the subject line (e.g., "NEW RESOURCE TYPE -
   example" to register an "example" relation type, or "NEW INTERFACE
   DESCRIPTION - example" to register an "example" interface
   description).

   Within at most 14 days of the request, the Designated Expert(s) will
   either approve or deny the registration request, communicating this
   decision to the review list and IANA.  Denials should include an
   explanation and, if applicable, suggestions as to how to make the
   request successful.

   Decisions (or lack thereof) made by the Designated Expert can be
   first appealed to Application Area Directors (contactable using
   app-ads@tools.ietf.org email address or directly by looking up their
   email addresses on http://www.iesg.org/ website) and, if the
   appellant is not satisfied with the response, to the full IESG (using
   the iesg@iesg.org mailing list).

   IANA should only accept registry updates from the Designated
   Expert(s), and should direct all requests for registration to the
   review mailing list.


comment:2 Changed 11 years ago by zach@…

Updated version of the registry with improvements from Barry and Cullen. Still open as to what mailing list will be used for registration requests.

7.4.  Registry for Resource Type and Interface Description Values

   This specification establishes two new sub-registries of Link
   Relations (defined in [RFC5988]), one for Resource Type (rt=) Link
   Target Attribute Values and the other for Interface Description (if=)
   Link Target Attribute Values.  No initial entries are defined by this
   specification for either registry.

   For both sub-registries, values starting with the characters "core"
   are registered using the IETF Review registration policy [RFC5226].
   All other values are registered using the Specification Required
   policy, which requires review by a designated expert appointed by the
   IESG or their delegate.

   The designated expert will enforce the following requirements:

   o  Registration values MUST be related to the intended purpose of
      these attributes as described in Section 3.

   o  Registered values MUST conform to the ABNF reg-rel-type definition
      of Section 2, meaning that the value starts with a lower case
      alphabetic character, followed by a sequence of lower case
      alphabetic, numeric, "." or "-" characters, and contains no white
      space.

   o  It is recommended that the period "." character be used for
      dividing name segments, and that the dash "-" character be used
      for making a segment more readable.  Example Interface Description
      values might be "core.batch" and "core.link-batch".

   o  URIs are reserved for free use as extension values for these
      attributes, and MUST NOT be registered.

   Registration requests consist of the completed registration template
   below, with the reference pointing to the required specification.  To
   allow for the allocation of values prior to publication, the
   designated expert may approve registration once they are satisfied
   that a specification will be published.

   Note that relation types can be registered by third parties, if the
   Designated Expert determines that an unregistered relation type is
   widely deployed and not likely to be registered in a timely manner.

   The registration template for both sub-registries is:

   o  Attribute Value:

   o  Description:

   o  Reference:

   o  Notes: [optional]

   Registration requests should be sent to the link-relations@ietf.org
   mailing list, marked clearly in the subject line (e.g., "NEW RESOURCE
   TYPE - example" to register an "example" relation type, or "NEW
   INTERFACE DESCRIPTION - example" to register an "example" interface
   description).

   Within at most 14 days of the request, the Designated Expert(s) will
   either approve or deny the registration request, communicating this
   decision to the review list and IANA.  Denials should include an
   explanation and, if applicable, suggestions as to how to make the
   request successful.

   Decisions (or lack thereof) made by the Designated Expert can be
   first appealed to Application Area Directors (contactable using
   app-ads@tools.ietf.org email address or directly by looking up their
   email addresses on http://www.iesg.org/ website) and, if the
   appellant is not satisfied with the response, to the full IESG (using
   the iesg@iesg.org mailing list).

comment:3 Changed 11 years ago by zach@…

  • Resolution set to fixed
  • Status changed from assigned to closed

Finalized in revision -13

Note: See TracTickets for help on using tickets.