- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 15 Oct 2007 11:38:34 +1000
- To: public-webapi@w3.org
Bjoern Hoehrmann: > So what do implementations actually allow now and in the future? It > seems to me, as you don't actually give precise rules for other schemes, > you might aswell say, implementations may support other schemes, and > must handle them in a manner analogous to HTTP, and possibly update the > specification if some new specification that maps other protocols onto > HTTP APIs that you can reference emerges. That is in effect what I’d like to say, but I was hoping to have it written with stricter requirements than just “analagous”. Perhaps that is not possible for the POST case while still being useful. > >By “functionally equivalent to HTTP” I mean “is the same as HTTP but > >happens to use a different URI scheme”, which is closer to the actual > >wording that would be included (“functionally equivalent” being a bit > >weasely). > > You mean if the underlying protocol *is* HTTP, right? Well, yes. > As I said, I do not think this is a particularily sensible > restriction. If some implementer can and wants to support postURL on > some additional scheme, they are highly likely to just ignore such a > restriction. Sure, if people want to disregard specs they will. But, as I say in my reply to Maciej, given that it is just that the underlying protocol is HTTP and that the request URI could just be replaced with one that has the http scheme, I think it’d be safe to drop this requirement. -- Cameron McCormack, http://mcc.id.au/ xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
Received on Monday, 15 October 2007 01:39:01 UTC