Define the atom:link element's rel attribute value as being either a URI (as defined by rfc2396bis) or a registered name in an IANA registry of relation types.
Related and Conflicting Proposals
This change provides a simple basis for extensibility of the atom:link element which has both the benefits of an IANA registry and those of a decentralized URI-based mechanism. In particular, it is intended to be both very simple and very extensible within the scope of links from this entry to other resources.
As with PaceLinkAttrDefaults, this proposal would reduce the most common case to
The value this has over XML namespaces is twofold:
1) it encourages standardization on a small set of commonly agreed terms by placing those terms in a community location and giving them efficiency-preference in the data format; and
2) the relation is defined as a form of content, rather than as a byproduct of XML name collision avoidance.
Hence, it is simple both for authors and the tools that process links (which may not have access to the whole XML infoset) and yet fully extensible for those who are not satisfied by the IANA registry.
Replace subsections 3.5.1 through 3.5.2 of draft-ietf-atompub-format-03 as follows; this adds a subsection and will bump following subsection numbers:
3.5.1 "rel" Attribute
Link constructs MAY have an optional rel attribute that indicates the link relation type. If the rel attribute is not present, the link construct MUST be interpreted as if the link relation type is "alternate".
rel_attribute = segment-nz-nc / URI
The value of rel MUST be either a name, which is non-empty and does not contain any colon (":") characters, or a URI [RFC2396bis, section 3]. Note that use of a relative reference to the rel value URI is not allowed. If a name is given, implementations MUST consider the link relation type to be equivalent to the same name registered within the IANA Registry of Link Relations, and thus the URI that would be obtained by appending the value of the rel attribute to the string "http://www.iana.org/assignments/relation/". The value of rel describes the meaning of the link, but does not impose any behavioral requirements on implementations.
3.5.2 Registry of Link Relations
This registry is maintained by IANA and initially contains the two values "alternate" and "related". New assignments must be approved by the IESG. Requests should be made by mail to IANA, which will then forward the request to the IESG requesting approval. The request should contain discussion of at least the following four topics:
Common name for link type.
Description of link type semantics.
Expected display characteristics.
The value "alternate" signifies that the URI in the value of the href attribute identifies an alternate version of the resource described by the containing element.
The value "related" signifies that the URI in the value of the href attribute identifies a resource to which the resource described by the containing atom:feed or atom:entry element is related. For example, the feed for a site which discusses the performance of the search engine at "http://search.example.com" might contain, as a child of atom:head:
<link rel="related" href="http://search.example.com/">
An identical link might appear as a child of any atom:entry whose content contains a discussion of that same search engine.
3.5.3 "type" Attribute
Link constructs MAY have a type attribute, whose value MUST conform to the syntax of an Internet media type [RFC2045].
The type attribute's value is an advisory media type; it MAY be used as a hint to determine the type of the representation which is expected to be returned when the value of the href attribute is dereferenced. Note that the type attribute does not override the actual media type returned with the representation.
Impacts: existing producers may want to take advantage of the new defaults. Consumers will have to deal appropriately with the new defaults.
See RFC 2434 for documentation on how to write an IANA Considerations section and define a registration procedure. In particular, note the distinctions between the policies of "Specification Required" and the higher-order "IESG Approval", "IETF Consensus", and "Standards Action". I suggest that Atom define this registry as provisional name assignment granted on a "First come, first served" basis. The name assignment becomes permanent when there are no outstanding objections after a period of six months and the equivalent of "Specification Required" is met, or if such objections are considered and overruled by "IETF Consensus". - RoyFielding