Subject: [Ecrit] Browser interface for service URNs

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 3 Feb 2007 15:49:20 -0500

Since we are having this discussion, let me briefly explain how  
"click to dial" for service URNs could work. It's actually pretty  
simple, and very similar to how tel and SIP URLs are implemented (in  
prototypes).

- You insert a service URN into the web page:

Call <a href="urn:service:sos">in an emergency only</a>

- The browser is configured, as described (via Windows registry or  
whatever mechanism), to hand off service URN to the right external  
handler, typically a media agent of some kind, such as a SIP user  
agent or Jabber client. That media agent already needs to understand  
service URNs and LoST if it is capable of emergency calls.

There are apparently efforts to support URNs in browsers, dating back  
ten years, with the first one being the most recent I found:

https://addons.mozilla.org/firefox/1940/
http://www.dlib.org/dlib/june98/06powell.html
http://www.persistent-identifier.de/english/550-MozillaPlugin.php

It wouldn't seem to be too hard to extend the current URN list in the  
Firefox extension to service URNs.

Since the browser itself isn't going to provide communication  
functionality natively, it needs to hand-off that aspect to an  
external agent in any event. The browser is also rather unlikely to  
know the user's location or support the various location query  
protocols, while the user agent has to have this functionality if it  
is to place emergency calls.

Plus, there's the obvious danger of getting users to reveal their  
location by an "innocent" click:

For a free iPod, click <a href="lost://evil.tracking.server.com/ 
foobar/some-cookie">here</a>!

That way, the "free" iPod site gets to associate your home address  
with your browser cookie. How convenient!

Thus, service URN functionality is quite useful, LoST functionality  
would only be useful if browsers were to essentially replicate a SIP  
user agent, including the phone-BCP functionality. As demonstrated,  
it could also be quite dangerous.

Henning

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Ted Hardie <[email-masked]>
Date: Sun, 4 Feb 2007 18:29:48 -0800

Henning,
	The critical difference here, and the one that makes this more of
a pain, is that most of the software out there treats the scheme as the indicator
of what to do; urn is seen as the scheme here.  You have to understand the
semantics of the specific namespace to understand what the resolution mechanism
will be for that NID.  RFC 2483 describes an experimental approach to the general
problem (and it is sufficiently dated that uses concepts like URCs, which have not seen
light from many days recently), but that and most of the other general-purpose
URN resolution mechanisms have failed.    I'd be happy for pointers to ones
that seem on the road to success, but the difference between the ease of
putting out something for a sip uri, a lost uri, and service urn remains pretty
basic:  implementers and deployers understand that schemes may be indicators
of what protocol processing to undertake, where urns do not carry that
same water.
	Given the lateness of the hour here, I think there are three ways
forward here.  One is that we take Patrik's original advice, strip the URI
out of the existing document and use only a dns name for the current
slots; we then file a provisional registration of "lost" to reserve the string
and get it out of the critical path (the disadvantage here is that you won't
be able to carry that information in slots requiring URIs until we're done with
that other work).  Second is that we  retain the URI and declare that the URI
may have parameters, which must be  registered; we then start the IANA registry,
but leave it blank--allowing the  discussion of whether either of the
proposed parameters make sense to go on a slower track than finishing the base document (the disadvantage here is that we may have an empty IANA registry
floating around if none are ever found useful).  The third is that we register the
URI for LoST as a host-only registration, and we allow it to be updated later
(the disadvantage here being that we would have a lot of trouble introducing
real change at that point).
	My preferences, at the moment, are the provisional registration
with a reversion to DNS name for the current protocol, followed by the
blank registry version.  But we're running very late on this at the moment,
so I hope we can agree on an approach quickly.
				Ted

At 3:49 PM -0500 2/3/07, Henning Schulzrinne wrote:
>Since we are having this discussion, let me briefly explain how "click to dial" for service URNs could work. It's actually pretty simple, and very similar to how tel and SIP URLs are implemented (in prototypes).
>
>- The browser is configured, as described (via Windows registry or whatever mechanism), to hand off service URN to the right external handler, typically a media agent of some kind, such as a SIP user agent or Jabber client. That media agent already needs to understand service URNs and LoST if it is capable of emergency calls.
>
>There are apparently efforts to support URNs in browsers, dating back ten years, with the first one being the most recent I found:
>
>It wouldn't seem to be too hard to extend the current URN list in the Firefox extension to service URNs.
>
>Since the browser itself isn't going to provide communication functionality natively, it needs to hand-off that aspect to an external agent in any event. The browser is also rather unlikely to know the user's location or support the various location query protocols, while the user agent has to have this functionality if it is to place emergency calls.
>
>Plus, there's the obvious danger of getting users to reveal their location by an "innocent" click:
>
>For a free iPod, click <a href="lost://evil.tracking.server.com/foobar/some-cookie">here</a>!
>
>That way, the "free" iPod site gets to associate your home address with your browser cookie. How convenient!
>
>Thus, service URN functionality is quite useful, LoST functionality would only be useful if browsers were to essentially replicate a SIP user agent, including the phone-BCP functionality. As demonstrated, it could also be quite dangerous.
>
>Henning
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 4 Feb 2007 21:38:10 -0500

> will be for that NID.  RFC 2483 describes an experimental approach  

Ted,

I fully realize that. One of the Firefox extensions I pointed to  
seems to deal with this just fine. At worst, you'd have to have a  
urn: scheme handler that ignores all the other (non-existing) URN  
NIDs for the browser.

> of what protocol processing to undertake, where urns do not carry that

We don't have to solve the general URN problem to make this work. The  
URN is only passed to the helper application (the SIP UA, say), which  
then does all the normal things that service URNs already do in those  
helper applications, including calling on LoST. The browser does not  
need to resolve the service URN at all, so the lack of a URN  
infrastructure or deployment does not matter in the least. Thus,  
comparisons to other URN applications are not particularly relevant  
here.

Any browser which is extensible in terms of schemes can handle the  
mechanism I described. Please explain why this is not the case.

> proposed parameters make sense to go on a slower track than  
> finishing the base document (the disadvantage here is that we may  
> have an empty IANA registry

The problem with the second approach is that the "shape" may be wrong  
if the URL were to ever require a path (lost://foo.com/something vs.  
lost:foo.com.) Thus, in addition to the reason you mention, I believe  
that this is not technically sound.

---

From: Ted Hardie <[email-masked]>
Date: Sun, 4 Feb 2007 19:29:53 -0800

At 9:38 PM -0500 2/4/07, Henning Schulzrinne wrote:
>Ted,
>
>I fully realize that. One of the Firefox extensions I pointed to seems to deal with this just fine. At worst, you'd have to have a urn: scheme handler that ignores all the other (non-existing) URN NIDs for the browser.

And it means that any general purpose-URN handler ever created must know of the
exception, and pass that NID to the right handler.  Otherwise, that general purpose
URN handler may  pre-empt the special purpose one--grabbing the URN before
URN:service is seen.

>
>We don't have to solve the general URN problem to make this work. The URN is only passed to the helper application (the SIP UA, say), which then does all the normal things that service URNs already do in those helper applications, including calling on LoST. The browser does not need to resolve the service URN at all, so the lack of a URN infrastructure or deployment does not matter in the least. Thus, comparisons to other URN applications are not particularly relevant here.

You're presuming that the URN is being passed to the helper application based on
what, here?  It being in the right slot in the using protocol?  In that case, I agree
that you don't need to solve the general problem of how protocols handle
URNs.  The problem, though, is what happens when you want to embed this
URI in something that is a generic URI slot--(and hrefs are not the only such);
that gets the handling we already agree is problematic.

>Any browser which is extensible in terms of schemes can handle the mechanism I described. Please explain why this is not the case.

This works as long as this is the only URN important the browser, by treating
urn:service as if it urn-service: .  That works if that is the only important URN,
but there may well be others that get handled differently (such as not triggering
resolution at all, but being treated as opaque identifiers).
>The problem with the second approach is that the "shape" may be wrong if the URL were to ever require a path (lost://foo.com/something vs. lost:foo.com.) Thus, in addition to the reason you mention, I believe that this is not technically sound.

I agree that this does constrain later addition, but since we're designing it, I
think it is reasonable to say anything we might want in a path could be put
into a parameter (if necessary, one called path).  Since you don't like this,
though, can we converge quickly on the first way forward?

					Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 4 Feb 2007 22:55:55 -0500

> URN handler may  pre-empt the special purpose one--grabbing the URN  

What you'd probably want is an extensible URN handler that can be  
configured to pass unknown NIDs to designated handlers. This doesn't  
strike me as particularly difficult, if a bit ungainly. I'll see if  
the Firefox URN handler, for example, can be easily extended that way.

> what, here?  It being in the right slot in the using protocol?  In  

Based on configuration in the URN handler. It would just have  
something like

service  sip-ua -dial %s

similar to the way that URL handlers are currently configured.

The service URN browser mechanism is needed independent of any LoST  
URL handling, so these issues are probably somewhat orthogonal.

> though, can we converge quickly on the first way forward?

That's probably the least-bad option.

Henning

---

From: Richard Barnes <[email-masked]>
Date: Tue, 06 Feb 2007 15:13:25 -0500

Using a URN in this way worries me, since the URN itself has no defined 
usage semantics, like an http: or sip: URI does (unless I'm misreading 
the service URN draft).  Just like ISBN URNs don't say to go to 
amazon.com over http, service URNs don't imply that a SIP call should be 
placed, or a coverage map retrieved over LoST, or anything else.

Rather, it seems like URNs should be inputs to something else, like
<a href="sip:urn:service:sos">Help!</a>, or even <br/>
<a href="lost://urn:service:pizza/serviceboundary">Hungry?</a>

I don't really think this impacts the fate of the lost: URI scheme, but 
URN's themselves don't really have the semantics to be used like you've 
propsed.

--Richard

Henning Schulzrinne wrote:
> Since we are having this discussion, let me briefly explain how "click 
> to dial" for service URNs could work. It's actually pretty simple, and 
> very similar to how tel and SIP URLs are implemented (in prototypes).
> 
> handler, typically a media agent of some kind, such as a SIP user agent 
> or Jabber client. That media agent already needs to understand service 
> URNs and LoST if it is capable of emergency calls.
> 
> functionality natively, it needs to hand-off that aspect to an external 
> agent in any event. The browser is also rather unlikely to know the 
> user's location or support the various location query protocols, while 
> the user agent has to have this functionality if it is to place 
> emergency calls.
> 
> For a free iPod, click <a 
> href="lost://evil.tracking.server.com/foobar/some-cookie">here</a>!
> 
> user agent, including the phone-BCP functionality. As demonstrated, it 
> could also be quite dangerous.
> 
> Henning
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 6 Feb 2007 15:19:47 -0500

Indeed, the actual service (voice, IM, telepathy-over-X.25) would be  
determined by user configuration and service availability. In a rough  
sense, this isn't all that different from a tel URL (which also  
doesn't indicate whether this is fax or voice) or a mailto URL (which  
also doesn't specify whether the protocol is SMTP or some other  
mechanism) or the im: and pres: URLs, which also don't specify a  
particularly protocol, but rather specify a "service".

Henning

On Feb 6, 2007, at 3:13 PM, Richard Barnes wrote:

> Using a URN in this way worries me, since the URN itself has no  
> defined usage semantics, like an http: or sip: URI does (unless I'm  
> misreading the service URN draft).  Just like ISBN URNs don't say  
> to go to amazon.com over http, service URNs don't imply that a SIP  
> call should be placed, or a coverage map retrieved over LoST, or  
> anything else.
>
> I don't really think this impacts the fate of the lost: URI scheme,  
> but URN's themselves don't really have the semantics to be used  
> like you've propsed.
>
> --Richard
>
>
>
>
>
>> simple, and very similar to how tel and SIP URLs are implemented  
>> (in prototypes).
>> agent or Jabber client. That media agent already needs to  
>> understand service URNs and LoST if it is capable of emergency calls.
>> There are apparently efforts to support URNs in browsers, dating  
>> back ten years, with the first one being the most recent I found:
>> external agent in any event. The browser is also rather unlikely  
>> to know the user's location or support the various location query  
>> protocols, while the user agent has to have this functionality if  
>> it is to place emergency calls.
>> Thus, service URN functionality is quite useful, LoST  
>> functionality would only be useful if browsers were to essentially  
>> replicate a SIP user agent, including the phone-BCP functionality.  
>> As demonstrated, it could also be quite dangerous.
>> Henning

---

From: "Desjardins, Pierre" <[email-masked]>
Date: Tue, 6 Feb 2007 17:19:50 -0500

My 2cents...

URLs were invented to formally convey the "location" and "access method"
of resources. Thus the scheme part of URLs was used to specify how the
resource location should to be "accessed" (http, ftp, mailto, ...) --
writing "im" and "pres" URLs extended that meaning to a certain extent.

URNs on the other hand were designed to convey persistent (location
independent) resource "identities". Additionally, whether or not the NSS
part is unique is NID-specific. In our case, writing
urn:service:sos.police is a persistent standin for whatever it
eventually "resolves" to.     

The list discussions so far seem to be using the service URN
(urn:service:sos.police for example) for both "identity" and "access"
purposes -- somewhat of an overload of the URN idea. It seems to me that
the "access" concept would become known through the usage context
(examples already pointed out by Richard):
	"sip:urn:service:sos.police" 
	"lost://urn:service:sos.police"
So the usage context for HTML HREFs could, for example, use a "serv" URL
scheme as in: "serv:urn:service:sos.police" -- which is conveying: call
upon (reference) the "service" whose identity is
"urn:service:sos.police".

- Pierre Desjardins

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, February 06, 2007 3:20 PM
To: Richard Barnes
Cc: ECRIT
Subject: Re: [Ecrit] Browser interface for service URNs

Indeed, the actual service (voice, IM, telepathy-over-X.25) would be
determined by user configuration and service availability. In a rough
sense, this isn't all that different from a tel URL (which also doesn't
indicate whether this is fax or voice) or a mailto URL (which also
doesn't specify whether the protocol is SMTP or some other
mechanism) or the im: and pres: URLs, which also don't specify a
particularly protocol, but rather specify a "service".

Henning

On Feb 6, 2007, at 3:13 PM, Richard Barnes wrote:

> misreading the service URN draft).  Just like ISBN URNs don't say to 
> go to amazon.com over http, service URNs don't imply that a SIP call 
> should be placed, or a coverage map retrieved over LoST, or anything 
> else.
>
> Rather, it seems like URNs should be inputs to something else, like <a

> href="sip:urn:service:sos">Help!</a>, or even <br/> <a 
> href="lost://urn:service:pizza/serviceboundary">Hungry?</a>
>
> but URN's themselves don't really have the semantics to be used like 
> you've propsed.
>
> --Richard
>
>
>
>
>

>> user agent, including the phone-BCP functionality.