- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 20 Jul 2009 14:03:07 +1000
- To: Noah Slater <nslater@tumbolia.org>
- Cc: Julian Reschke <julian.reschke@gmx.de>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 20/07/2009, at 2:22 AM, Noah Slater <nslater@tumbolia.org> wrote: > * Why does the specification link to: > > http://www.iana.org/assignments/relation/ > > This page doesn't exist. > > The changelog suggest that this should have been removed: > > o Removed specific location for the registry, since IANA seems to > have its own ideas about that. > > Instead of removing the location, should IANA sort out the > existing mess? It's currently in process. > * Why does the specification omit details available in the current > registry. Because many of the characteristics in the atom registry were found to be useless in practice; eg "display characteristics" was very often "none" and furthermore it encouraged format-specific (and often, use- case specific) relations to be defined. Many uses of Atom (let alone other formats) don't even have a display component. Likewise, Security Considerations is specific to an application, not the relation between two resources. Reference and registration date will be populated by IANA. > * Why does the specification add the specification requirement? The > previous > relations added without specification seem quite useful. Do we > really want > to prevent relations like that being added? They were often just a few words sent to IANA without much explanation, coordination or forethought. Since the whole idea is for the registered relations to be ones with common semantics and shared uses, having an actual specification that has *some* level of community behind it makes sense. This isn't preventing relations from being added, it's making sure they're unambiguous and well-thought-out. Besides, there are always extension relations, which I expect is where most of them -- particularly those that are more application-specific -- will go. Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Monday, 20 July 2009 04:03:46 UTC