Subject: [Sipping] use of SIP URI for announcements

From: "Christian Huitema" <[email-masked]>
Date: Thu, 9 Aug 2001 01:07:12 -0700

After the WG discussion today, I had a chat with Eric and noticed the similarity between the annoucement problem and a similar issue in SOAP, in which URL are used to describe protocol elements, such as for example SOAP "actions." The protocol handling of these actions is similar to the way a SIP agent is supposed to handle, for example, an announcement: exercize the local implementation of the object named "X". The way they do that is, use a URL that uniquely defines the action; it could be something like, for example:

		http://w3.org/html/get

		http://iana.org/sip/invite

In the case of announcements, the obvious parallel will be to use a complete URL to define the annoucement, i.e. use both the left and the right hand sides of the URL. For example, if you want to play a generic "welcome" message, the URL could be "sip:[email-masked]" -- while a message specific to the "example" corporation would be "sip:[email-masked]".

-- Christian Huitema

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Thu, 9 Aug 2001 08:02:16 -0500

Please do not take this approach. Standardizing
a URL that implies something of global significance
especially an action to take is a horrible abuse
of URLs. Yes, SOAP and XML have done this. But 
it is a really bad idea. At least use a URN instead.

/sean

>-----Original Message-----
>From: Christian Huitema [mailto:[email-masked]]
>Sent: Thursday, August 09, 2001 3:07 AM
>To: [email-masked]
>Subject: [Sipping] use of SIP URI for announcements
>
>
>After the WG discussion today, I had a chat with Eric and 
>noticed the similarity between the annoucement problem and a 
>similar issue in SOAP, in which URL are used to describe 
>protocol elements, such as for example SOAP "actions." The 
>protocol handling of these actions is similar to the way a SIP 
>agent is supposed to handle, for example, an announcement: 
>exercize the local implementation of the object named "X". The 
>way they do that is, use a URL that uniquely defines the 
>action; it could be something like, for example:
>
>		http://w3.org/html/get
>
>In the case of announcements, the obvious parallel will be to 
>use a complete URL to define the annoucement, i.e. use both 
>the left and the right hand sides of the URL. For example, if 
>you want to play a generic "welcome" message, the URL could be 
>"sip:[email-masked]" -- while a message 
>specific to the "example" corporation would be 
>"sip:[email-masked]".
>
>-- Christian Huitema
>
>

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 9 Aug 2001 10:01:35 -0400

I guess I wasn't clear in the presentation (although the draft is): I'm not proposing standardizing the tokens in msuri.  I am proposing a use of a URI _convention_ such that when someone wishes to request a service from (in this case) a media server, *and* that media server conforms to the _convention_, the individual does not have to negotiate a closed, proprietary method for accessing the service.

In no way does the draft propose that the *only* way to access a given service (e.g., announcements) is to use [email-masked].  Likewise, SIP UAS' do *not* have to implement the service schema.  The draft states (and I'll make it even more clear in the next draft) that the SIP Request-URI remains an opaque object.  However, if you *choose* to provide services at well-known locations, you are free to do so.

Said differently, if you want to put "sip:[email-masked]" on your business card, you can.  Likewise, if you buy a media server and put it into your network, you know that you can write a portable application by requesting announcements from "sip:[email-masked]".

The "well-known location" part is why we're speaking about an IANA registry.

Why did we introduce a _convention_ (not standard) for labeling something a conference?  First, I'd like to point out that from a SIP perspective, "[email-masked]" and "conf=[email-masked]" are both valid ways of addressing a conference.  The only difference is the opaque identifier (the entire URL, LHS and RHS) of the former is five characters shorter than the latter.  The fact that we chose those extra five characters is transparent to SIP.  Said differently, you can always setup a conference by INVITING a bunch of people to [email-masked].  We are proposing that you may chose (but are not required) to INVITE the bunch of people to conf=[email-masked].

The primary motivation for the draft is that some UAS', like a media server, can do more than just be a conference bridge / mixer.  They can play announcements, do transcoding, initiate IVR, etc.  What we need is a way to indicate to the UAS which service to invoke.  The approach of the draft is that the different services are simply different "called parties" at the media server.  It happens that we define some called parties to be announcements, others are transcoding sessions, and yet others are traditional mixers.  It also happened that we defined a schema to make it possible for the media server to determine which "called party" was of interest to the caller.

Why did I propose using a URL instead of a URN or global lookup service?  My motivation was so that the service would work entirely within the existing SIP architecture.  For example, we envision service provider nodes (media servers) will register their services with a SIP registrar.  By registering as an endpoint for "[email-masked]", a proxy can chose any registered media server that serves announcements.  If we made each announcement itself an object, then a central registry would be extraordinarily large (easily hundreds of millions of entries).

Another possibility we rejected was to encode the service on the RHS of the Request-URI, such as "[email-masked]" and "[email-masked]".  That requires too much DNS setup (or hacking).

Another possibility we rejected was to indicate the service as a SIP header.  The choices we looked at was to do something like "announce: http%2d//audio.carrier.net/allcircuitsbusy.g711" or "media-server: announce;http%2d//audio.carrier.net/allcircuitsbusy.g711".  However, we really wanted to stay out of the "make SIP look like MGCP" game.

Another possibility we considered, but didn't expect to be practical, was to indicate the service in the INVITE payload.  The problem there is that we found out that not all proxies were well written and that we might come across ALG problems with multiple multi-part INVITE bodies.

Another issue that I might not have been clear about: we by no way are proposing the content of the service.  For example, in the announcement case, we believe that something like "annc=[email-masked]" is NOT a good thing.  That means that we would be dictating the content of all announcement servers.  See the network announcement draft for the approach we did take.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Thursday, August 09, 2001 9:02 AM
To: 'Christian Huitema'; [email-masked]
Subject: RE: [Sipping] use of SIP URI for announcements

/sean

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 09 Aug 2001 16:45:00 +0100

[email-masked] writes:
>is a horrible abuse
> of URLs. Yes, SOAP and XML have done this. 

SOAP and XML are the result of the work of W3C.

Are you contesting the authority of W3C? Have you you taken it up with
W3C?

Thanks, Henry

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Thursday, August 09, 2001 2:02 PM
> >Use [email-masked] for questions on 
> current sip Use 
> >[email-masked] for new developments of core SIP
> >
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 09 Aug 2001 11:35:08 -0500

I am very concerned about any trend (standard or otherwise) towards 
assigning global meaning to URLs. I find a _convention_ even more 
dangerous than a _standard_.

Imagine a scenario: Your email system doesn't let you actually enter an 
email address. Instead, it asks you for the first and last name of the 
recipient, as well as their domain. From that, it follows the common 
convention of mailto:first.last@domain. But my email address is 
mailto:[email-masked]. Your system _cannot_send_me_mail_.

The only way to solve this problem is to assert that all email systems 
_MUST_ follow the convention, or to assert that all email systems should 
allow you to enter arbitrary email addresses.

Additionally, if we create such a convention for sip, then everyone will 
have to use care not to accidentally assign a URL or URL format with 
global meaning for some other use. This is true even if they do not 
support the convention, since others are likely to _assume_ they support 
the convention.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 11 Aug 2001 21:51:58 -0400

Any mechanism can be abused. For email, we already have 'standard' email
names, a whole list including hostmaster, postmaster, webmaster, etc.,
which has turned out to be useful, I think.

In this particular case, I very much doubt that the special URLs would
appear in UIs. Where I see some value is that it makes it easier to
write scripts that are more likely (albeit not guaranteed) to be
portable across vendors.

It probably wouldn't hurt to give some 'usage' guidelines in the draft,
in particular addressing the issue of not constraining what user agents
can and cannot use.

> support the convention, since others are likely to _assume_ they support

This is no different than assigning 'root' as a username. At worst,
you'll get some mail meant for the super user on your machine. Again, in
the model I mentioned, I see this as valuable for local forwarding
scripts, for example, not for dealing with remote systems. There are far
too many different URLs, even with this mechanism, to make guessing
viable.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 13 Aug 2001 20:36:30 +0300

Hello,

My email address is mailto:[email-masked]. I would like
it to remain like that, and not turn into
mailto:Surname=Gonzalo.FamilyName=[email-masked]

The fact that some servers will use conf=[email-masked] does not save
anything. I will have to configure my UA, anyway, with that URL. It
would have been the same effort for me to write [email-masked] in the
configuration file of my UA instead.

One might claim that structured user names are easier to guess, but I do
not think that any serious system will based service provision on
guessing URLs (even if they follow a particular convention).

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: Michael Hammer <[email-masked]>
Date: Mon, 13 Aug 2001 14:01:29 -0400

Gonzalo,

What you don't like X.400 style addressing?  :-)

Mike