- From: Erik Wilde <dret@berkeley.edu>
- Date: Tue, 23 Feb 2010 11:34:13 -0800
- To: URI <uri@w3.org>
hello. http://tools.ietf.org/html/draft-ietf-geopriv-geo-uri-04 is the most recent version of a proposed URI scheme for geolocation. this scheme establishes a new IANA registry for scheme parameters in general, as well as a specific sub-registry for coordinate reference systems (one pre-defined parameter) used for geolocation values. i have two general questions about this: - in general, is there some guideline/policy on how extensibility and registries should be designed for URI schemes? the proposed scheme allows to dynamically create new sub-registries for parameters which take predefined values. this means that the proposed registry structure is actually fairly complex. - specifically, the registry proposed in this draft contains information (the geolocation coordinate reference system) that maybe should be shared across technologies. the W3C geolocation API, for example, also uses a geolocation coordinate reference system. the proposed HTTP location protocol http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-16 also uses a geolocation coordinate reference system. is there some guideline/policy that tries to avoid such a duplication of information? in this specific case, i think the way to go would be to have an ID for describing the geolocation concepts, and then have specific technologies (such as the URI scheme and the geolocation API) refer to that ID. this worked for languages and country codes, but maybe because there was an external entity (ISO) managing those lists? does the IETF have a process that helps to implement this design pattern without help from the outside? generally speaking, registries are a good thing to keep things evolvable and extensible, but registry sprawl seems to be a problem. and since registries typically have no API, it is almost impossible to write code that uses registries in a meaningful way. API-enabled registries probably are no problem at all (the DNS is more or less that, i would argue), but API-less registries might make it hard to implement support for URI schemes using this kind of extensibility. kind regards, erik wilde tel:+1-510-6432253 - fax:+1-510-6425814 dret@berkeley.edu - http://dret.net/netdret UC Berkeley - School of Information (ISchool)
Received on Tuesday, 23 February 2010 19:34:43 UTC