policy question on URI specs (from sms: discussion)

In a lengthy off-list discussion of 

       http://tools.ietf.org/html/draft-wilde-sms-uri-12  

we came to what seemed to me to be a policy question of whether URI schemes are better off defining all of the options one might want to use (in this case, the telematic interworking specifications) or to intentionally limit the syntax to things that can be trusted to be implemented by most all interpreters.  

I thought I would raise the more general policy issue on the URI list. (Excerpts from conversation below).


[Larry]
> I'm starting to think that it would be better to leave out all the extra signaling stuff that someone *might* want to say, and instead just have a simple scheme:
>    sms:<telephonenumber>
> and don't define anything else. It would be simple, straightforward, secure, and interoperable. It's OK if there's no way of signaling other features that won't be widely implemented anyway.

[Erik]
that would remove half of the spec....  not that that is out of the  question, and you are definitely right that in most cases the telematic interworking will not be supported ... maybe there are scenarios where telematic interworking is still required. i used it quite a lot when phones still supported it somewhat, but now most phones don't support it at all, so it is hard to use, even if you want to.

[Larry]

> (There's no way to signal HTTP request headers in http: URIs for example. It's OK. It would be a bad idea to add a lot of decoration to add it. The request headers are up to the client.)

[Erik]
...  i actually think that it would be better to have some well-defined interaction between http uris and the protocol mechanics. http://dret.net/lectures/publishing-spring07/i18n+l10n#(30) is one good reason for this, the inability to create a uri for selecting a variant of a content negotiated resource is something that keeps people from setting up well-configured internationalized web servers. i don't see why that would be a bad thing, on the contrary, i think it would be a very good thing, but i also see that it is not going to happen.

think of location-negotiated resources. let's say i want to identify the resource with berkeley's movie program. with well-designed interaction of uris and http, i could say http://movies.com/program;location=berkeley

Received on Friday, 21 September 2007 14:17:31 UTC