[
Lists Home |
Date Index |
Thread Index
]
> > Thought why he wouldn't want it to identify himself, rather than an HTML
> > page is a different question. Certainly just *because* the GET returns
> > an HTML when you ask it for that (all browsers ask for text/html),
> > doesn't mean that the URI identifies the HTML. HTML is one
> > *representation* of the resource, not necessarily the resource itself.
>
> But therein lies the problem. It could spurt out a nice HTML page about me
> with pictures and everything, but all that static data can do is describe me.
What else would you expect of a digital representation?
> The static data could contain my phone number allowing me to be rung, but
> then that's escaping the Web model.
No, that's exactly the Web model, especially if the link to your phone
number were typed;
<a href="urn:oid:1.2.826.0.1.4072548.2.0"
rel="http://phone.org/phonenum">
Call me</a>
> > telnet some-mobile-phone-provider.com 80
> >
> > GET urn:oid:1.2.826.0.1.4072548.2.0 HTTP/1.1
> > Host: some-mobile-phone-provider.com
> > Accept: text/plain
>
> Hey! That wasn't an HTTP URL.
Nope, but HTTP GET is suitable for resolving all URI, not just HTTP
scheme URI. The intermediary features of HTTP/REST explicitly permits
this.
> And who told you that
> some-mobile-phone-provider.com would be able to resolve that URN, hmmm?
You could, if you wanted;
telnet alaric-snell.com 80
GET urn:oid:1.2.826.0.1.4072548.2.0 HTTP/1.1
response;
HTTP/1.1 305 Use Proxy
Location: http://some-mobile-phone-provider.com
But sure, it's always easiest to use an HTTP scheme URI because you
don't have to worry about this boostrapping problem. For example,
there is no reason why your phone couldn't be identified by;
http://some-mobile-phone-provider.com/subscriber/1.2.826.0.1.4072548.2.0
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker@planetfred.com
http://www.markbaker.ca http://www.planetfred.com
|