Subject: Re: [Sip] Additional uses of INFO

From: Alan Bergmin <[email-masked]>
Date: Wed, 21 Jun 2006 14:24:03 -0700 (PDT)

> MESSAGE is INFO, except that INFO is supposedly always 
  > in a dialog
  
> Do we have to change HTTP every time somebody uses 
  > it to get a new type of image file or to build a new type 
  > of web application? Let me think . . . nope, we don't.

  I fully agree. I think that discussions about a new CONSENT request have shown that people do not want to increase the complexity of the SIP protocol with new requests. I really prefer new content-types for an existing INFO request.

   

 		
---------------------------------
Yahoo! Groups gets better. Check out the new email design. Plus there’s much more to come.  

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Jun 2006 13:44:27 -0400

This whole argument is based on the model that a new method is somehow a 
  big change in SIP, whereas a new body is a small one. Why is that?

-Jonathan R.

Alan Bergmin wrote:

> I fully agree. I think that discussions about a new CONSENT request have 
> shown that people do not want to increase the complexity of the SIP 
> protocol with new requests. I really prefer new content-types for an 
> existing INFO request.
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> 
> ------------------------------------------------------------------------
> Yahoo! Groups gets better. Check out the new email design. 
> <http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=41142/*http://groups.yahoo.com/local/newemail.html> 
> Plus there’s much more to come.
> 
> 
> ------------------------------------------------------------------------
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Dean Willis <[email-masked]>
Date: Thu, 22 Jun 2006 14:08:42 -0500

On Jun 22, 2006, at 12:44 PM, Jonathan Rosenberg wrote:

> This whole argument is based on the model that a new method is  
> somehow a  big change in SIP, whereas a new body is a small one.  
> Why is that?
>

because it is true?

The bodies are normally processed in code external to the SIP stack,  
whereas methods are processed in the SIP stack itself.

Again, I'd like to resort to "HTTP as a model". It's not incredibly  
clean, but it has had some successes.

Even with Netscape Navigator version 1.0, we could define "helper  
applications" for different body types. Using this technique, a  
browser could deliver content with any arbitrary MIME type to the  
right application without changing the browser code in any way.

The content doesn't change the function of HTTP, which is still doing  
the same old "get" and "put" and "post" operations.

This doesn't mean the the content is unimportant to the HTTP-using  
application. For example, someone might decide they like the image  
displayed next to a link and therefore click the link. This doesn't  
make the "attractiveness of that image" a part of the HTTP protocol.  
In fact, HTTP doesn't even know that the blob was an image -- it just  
sees it as an arbitrary stream of bytes associated with a content- 
type tag.

SIP applications could benefit from the same sort of layering. SIP  
should do its INVITE, SUBSCRIBE, REGISTER, NOTIFY, and INFO  
operations completely independently of the bodies being carried by  
the SIP messages.

The SIP design pattern of using a new request-type for every "data  
purpose" is analogous to trying to encode HTML mark-up into the HTTP  
protocol itself.

Imagine a bizarro-world variation on HTTP, where one issued a "GET- 
TEXT" request to get the plain text on a page, then a "GET-LINK"  
request for each link, a "GET-IMAGE" request for each image on the  
page,  "GET-SOUND" for embedded sound (and so on) and used some sort  
of XPATH variation to knit everything back into an HTML document that  
could be rendered. Then try and do this in real-time, and you'd get  
something very much like where the current SIP pattern is taking us.

--
dean

---

From: <[email-masked]>
Date: Thu, 22 Jun 2006 23:35:56 +0300

Hi,

Also, the perception of the time it takes in the IETF to standardize different things is different. Most people who just want to do something with SIP become horrified if a SIP usage/extension policy expert says that what they are doing is fine, but that it requires a new method in SIP. New headers are not quite as bad, and new content types for existing methods seem to be the least painful route. Although people become quite puzzled when you tell them that INFO is not supposed to be used and MESSAGE can't exceed 1300 Bytes.

Another thing is that based on my practical experience, many deployed SIP networks indeed block the methods they do not know or care about, even such things like SUBSCRIBEs. (And these are not even IMS based.) So, reuse of the old methods may be preferred in those cases.

One thing that bothers me a bit in SIP that we don't have anything that could serve as a generic transport between two SIP endpoints. XMPP, for instance, is more flexible in this sense. Of course you can setup whatever as a media in a SIP session and run things on top of that, but even in that case there could be something standardized that people could easily use. (MSRP was not done based on that kind of requirement, but it is perhaps the closest there is.)

So, I think the average SIP users (meaning developers who want to do something with SIP) have quite a different view on this than the IETF.

Regards,
	Markus

-------------------------------
Markus Isomäki
[email-masked]
-------------------------------

>-----Original Message-----
>From: ext Dean Willis [mailto:[email-masked]] 
>Sent: 22 June, 2006 22:09
>To: Jonathan Rosenberg
>Cc: [email-masked]
>Subject: Re: [Sip] Additional uses of INFO
>
>
>> This whole argument is based on the model that a new method 
>is somehow 
>> a  big change in SIP, whereas a new body is a small one.
>> Why is that?
>>
>
>because it is true?
>
>The bodies are normally processed in code external to the SIP 
>stack, whereas methods are processed in the SIP stack itself.
>
>Again, I'd like to resort to "HTTP as a model". It's not 
>incredibly clean, but it has had some successes.
>
>Even with Netscape Navigator version 1.0, we could define 
>"helper applications" for different body types. Using this 
>technique, a browser could deliver content with any arbitrary 
>MIME type to the right application without changing the 
>browser code in any way.
>
>The content doesn't change the function of HTTP, which is 
>still doing the same old "get" and "put" and "post" operations.
>
>This doesn't mean the the content is unimportant to the 
>HTTP-using application. For example, someone might decide they 
>like the image displayed next to a link and therefore click 
>the link. This doesn't make the "attractiveness of that image" 
>a part of the HTTP protocol.  
>In fact, HTTP doesn't even know that the blob was an image -- 
>it just sees it as an arbitrary stream of bytes associated 
>with a content- type tag.
>
>SIP applications could benefit from the same sort of layering. 
>SIP should do its INVITE, SUBSCRIBE, REGISTER, NOTIFY, and 
>INFO operations completely independently of the bodies being 
>carried by the SIP messages.
>
>The SIP design pattern of using a new request-type for every 
>"data purpose" is analogous to trying to encode HTML mark-up 
>into the HTTP protocol itself.
>
>Imagine a bizarro-world variation on HTTP, where one issued a 
>"GET- TEXT" request to get the plain text on a page, then a 
>"GET-LINK"  
>request for each link, a "GET-IMAGE" request for each image on 
>the page,  "GET-SOUND" for embedded sound (and so on) and used 
>some sort of XPATH variation to knit everything back into an 
>HTML document that could be rendered. Then try and do this in 
>real-time, and you'd get something very much like where the 
>current SIP pattern is taking us.
>
>--
>dean
>
>This list is for NEW development of the core SIP Protocol Use 
>[email-masked] for questions on current sip

---

From: Michael Thomas <[email-masked]>
Date: Thu, 22 Jun 2006 15:13:36 -0700

Dean Willis wrote:

>> somehow a  big change in SIP, whereas a new body is a small one.  Why 
>> is that?
>>
>
> because it is true?
>

So it's your position that you'd like SIP to be a generic transport 
protocol which is
what HTTP has become (from the expected to the grotesque)? Versus being a
redezvous protocol which leads to the transport with some other protocol 
like, oh say,
HTTP?

I guess what I find weird about SIP's collapse into a transport protocol 
for anything
and everything is that it's got all of this heavy proxy machinery, 
forking and all kinds
of other stuff for its primary job which leaves it pretty suboptimal for 
a whole variety
of reasons, not the least of which is the inherent security issues of 
content through
3rd parties whose intentions are dubious.

That and SIP's complexity has long since spiralled out of control. It 
seems to me that
HTTP gets by pretty well because it doesn't attempt to be the last word 
on signaling
protocols. But SIP signals a lot of different things for a lot of 
different purposes, and
instead of getting relatively light weight signaling with heavy weight 
content (HTTP),
going where you're suggesting would get you heavy weight signaling with 
heavy
weight content -- and the inherent combinatorics.

Last parting shot: I once asked Cullen whether anybody had ever 
implemented all of
the SIP RFC's into a single stack. As I recall, he just laughed. Let's 
suppose that somebody
were so inclined to do so, would it have any prayer of being passably 
self-consistent? Or
dare I say work, FSVO work? What does this say, especially in light of 
your position?

       Mike

---

From: Dean Willis <[email-masked]>
Date: Thu, 22 Jun 2006 23:39:46 -0500

On Jun 22, 2006, at 5:13 PM, Michael Thomas wrote:

> redezvous protocol which leads to the transport with some other  
> protocol like, oh say,
> HTTP?

well, it IS a generic transport protocol. Every time somebody comes  
up with a new application that sounds reasonable, we make a new  
extension to accommodate them. This is where a lot of our complexity  
has come from.

>
> I guess what I find weird about SIP's collapse into a transport  
> protocol for anything
> of other stuff for its primary job which leaves it pretty  
> suboptimal for a whole variety
> of reasons, not the least of which is the inherent security issues  
> of content through

Some of this stuff I'll admit I'd like to rip out. But from another  
perspective, it is some of these capabilities that are driving  
interest in SIP as a transport protocol for new applications.

> the SIP RFC's into a single stack. As I recall, he just laughed.  
> Let's suppose that somebody
> were so inclined to do so, would it have any prayer of being  
> passably self-consistent? Or
> dare I say work, FSVO work? What does this say, especially in light  
> of your position?

No doubt. I'd actually like to make a much narrower cut at "core  
SIP". A lot of the things that people seem to think need RFCs -- for  
example, request-URI parameters, I think need only FCFS or possibly  
"spec required" IANA process. The same is probably true for body types.

--
Dean

---

From: Michael Thomas <[email-masked]>
Date: Fri, 23 Jun 2006 06:35:46 -0700

> extension to accommodate them. This is where a lot of our complexity  

I know that, but the question to ask is whether it's a very _good_ transport
protocol for the jobs it's being asked to do. SIP carries a lot of 
baggage given
its original purpose in life, and you start running into the 
combinatorics of all
of these cross-purposes, and most especially from us dumb dilitante 
programmer
types who don't know the ground rules via years of working group osmosis.
And even for somebody like me whose main SIP dilitantism is reading this 
list, I sure
see an awful lot of stump-the-expert kinds of questions, and many seem
to fall into either the base complexity, or the "what does this feature 
meant for
this purpose mean in the context of that feature meant for that purpose".

If you then combine this with the complexity of addition of unlimited body
complexity ala http, will any of this still work? And then all of the 
security
mechanisms layered on? What about their cross purposes? I've been dealing
a lot of with email security lately, and it's hard enough to keep that 
for what
approximates straight in my mind, and email is dead simple in comparison
to SIP, IMO.

> "spec required" IANA process. The same is probably true for body types.

Maybe part of the problem here is that SIP is more constrained than the 
analogous
HTTP in that there really doesn't need to be anything more than a 
defacto standard
to serve up new content types, unlike the intricacies of the control plane.

But you took a pass on my question about why you don't just use SIP to 
do what
it's good for: find things and establish sessions, and let other 
protocols do the work
in their own domain. Is there an existence proof beyond SDP/RTP these 
days? It
seems if SIP were originally made to set up sessions for hair cutting 
appointments,
somebody today would have the great idea of putting RTP over SIP, and who
could say they were wrong?

       Mike

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 21 Jun 2006 22:13:25 -0400

I may have missed the discussion, as I've had to rejigger my e-mail,
but given the highly non-standardized use of INFO, how do
implementations determine whether they can understand an INFO that
they receive?

It strikes me that it might be possible to allow the different uses of
INFO to be distinguished (via x-* Content-Types, probably), without
having to commit ourselves to any further standardization.  This would
significantly avoid interoperability problems, I think.

That's not as comprehensible a solution as Jonathan's proposal, but it
is something that can be done by current implementations to get rid of
the worst problems.

Dale

---

From: Dean Willis <[email-masked]>
Date: Fri, 23 Jun 2006 13:03:47 -0500

On Jun 23, 2006, at 8:35 AM, Michael Thomas wrote:
>
>
> But you took a pass on my question about why you don't just use SIP  
> to do what
> in their own domain. Is there an existence proof beyond SDP/RTP  
> these days? It
> seems if SIP were originally made to set up sessions for hair  
> cutting appointments,

Pretty simple, really. The security and firewall-traversal and  
correspondent discovery mechanisms make it extremely useful as a  
transport protocol, especially when it is transporting "stuff" that  
is ancillary to a real-time communications session.

Sure, we could set up an additional parallel session to transport the  
"stuff", but since all the fundamental mechanisms are already there  
in SIP, why bother? MSRP does define a use case where that "why  
bother" is answered such that we have agreement to do a parallel  
session, but I've personally never been incredibly comfortable with  
that agreement.

There are lots of telephony applications of SIP where the "Stuff"  
being transported is signaling data that's only meaningful in the  
telephony world and it just needs to get across the IP net to to  
another GSTN UA on the other side. That should provide an "existence  
proof", and is the currently agreed use-case for INFO.

Another "existence proof' is instant messaging using MESSAGE  
requests, as implemented in at least one popular client and lots of  
specifications. Success here is why I'm not so sure about the need  
for MSRP.

Message waiting indicator, even in  the crippled implementation (no  
SUBSCRIBE) of today's Linksys, provides us yet another proof-point,  
and a glimpse of the massive versatility of the SIP event framework.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 23 Jun 2006 13:08:31 -0500

> implementations determine whether they can understand an INFO that

Ah. You have there the tip of the INFO problem. We don't have a  
mechanism to answer this question, and if we were going to do  
anything BUT GTSN using INFO, we'd need to develop such a mechanism.  
Thus, two choices -- 1) block all further use of INFO, and 2) add a  
usage-negotiation mechanism to INFO, just as we did for SIP Events.

> significantly avoid interoperability problems, I think.

Content-type tells about what the content is. Content-disposition  
tells about what one is supposed to do with the content, and might be  
a better candidate for this sort of usage. Or perhaps a combination  
of the two.

If I send you an image/jpeg during a call, what do you do with it?  
Display it? Add it to your phone book next to my name? Run a  
steganographic search on it to look for a hidden message?

> is something that can be done by current implementations to get rid of

There may be a middle ground option somewhere here.

--
dean

---

From: Michael Thomas <[email-masked]>
Date: Fri, 23 Jun 2006 11:36:24 -0700

> session, but I've personally never been incredibly comfortable with  

Well, one reason to bother is complexity, and especially complexity that is
at least partially borne out of needing to work around the additions of 
complexity
for other mostly unrelated purposes. Take for example, oh say, 
sip-identity or
S/MIME. Has anybody really gone through all of the use cases of SIP in its
full glory to see if is even relevant let alone useful? And if it's not 
relevant,
does that mean that a need is going unmet but we just don't know it yet? And
if that's the case, will that unmet (future) need be met by 
shoe-horning, say,
sip-identity (which is in the SIP universe and therefore more malleable) in
potentially grotesque ways never envisioned, and probably mostly 
inappropriate?
Or do we invent a new mechanism which is more appropriate for the task, but
then get to wonder what happens if they interact with the other SIP 
mechanisms?

At some point, all you're really doing is tunnelling new "stuff" over 
port 5060.
The same can, of course, be said of HTTP, but my sense is that HTTP is still
quite a bit leaner at the signalling layer which mitigates the creep to 
some
degree. But SIP is very complicated at the signaling layer and getting 
moreso
every passing year. I understand the expediency of reusing an existing 
channel,
but suppose that we were having this same argument about shipping telephony
signaling, etc, over an HTTP substrate. They can djinn up new methods too,
after all. Would this be a wise thing for HTTP to take on? Or would you --
IMO properly -- say "go get your own port to play with"?

> and a glimpse of the massive versatility of the SIP event framework.

Sorry if I'm being dense here, but aren't these all sessions that run 
over SIP itself?
I was curious if there was anything else that was establishing sessions 
via SIP like
SDP/RTP -- ie, where SIP, um, initiated it but otherwise mostly gets out 
of the way.

       Mike

---

From: [email-masked]
Date: Fri, 23 Jun 2006 16:03:35 -0400

[Let's see if I've finally started using e-mail addresses right here.]

Now that I think about it a little more, it seems to me that we're
getting over-wrought about things.  If an implementation wants a
private mechanism, that is, one that only interoperates with a handful
of other implementations, there are a number of avenues of
extensibility, all of which will be treated by other implementations
in a standardized (or at least conventionalized) way:

    Information             Technique               Default interpretation  

    new method              X-* method              405 response

    new header              X-* header              ignored

    new session type        new x-* Content-Type    415 response
                            in INVITE

    new data lump           new x-* Content-Type    415 response
    transport               in INFO

    new extension           new x-* option-tag      420 response
    identifier

(And there are a number of others.)

In every case, as long as the implementation that understands the
extension is prepared to recognize the default interpretation as a
situation where the extension cannot operate, there should be no
serious interoperability problems.

Of course, if someone wants an extension with wide interoperability,
they're stuck going through the whole WG process, or something very
similar in another forum, just because that's the only way to get a
wide range of implementors to agree on how to do something.

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jun 2006 16:33:36 -0400

Dean Willis wrote:

> applications" for different body types. Using this technique, a  browser 
> could deliver content with any arbitrary MIME type to the  right 
> application without changing the browser code in any way.
> 

This is because HTTP has a much cleaner separation between HTTP and the 
application that sits ontop of it. HTTP merely passes content, and the 
thing ontop 'renders' it.

SIP doesn't have such a clean notion of an 'application' that sits ontop 
of SIP. Data that, for one implementation, looks like 'applciation 
data', might be processed by the 'core sip stack' on the other end. 
Thats because SIP is meant to address a specific application itself - 
interactive communications.

> Another thing is that based on my practical experience, many deployed SIP networks indeed block the methods they do not know or care about, even such things like SUBSCRIBEs. (And these are not even…

well, nothing in the specs say you should do that. In fact, they say 
quite the opposite. So who is to say that, once we define INFO usages, 
those same networks just won't block everything except for the SIP-T 
ISUP porting usage we have today, for the same reason they block new 
methods?

Thanks,
Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Fri, 23 Jun 2006 16:13:02 -0500

On Jun 23, 2006, at 1:36 PM, Michael Thomas wrote:
>
> Sorry if I'm being dense here, but aren't these all sessions that  
> run over SIP itself?
> I was curious if there was anything else that was establishing  
> sessions via SIP like
> SDP/RTP -- ie, where SIP, um, initiated it but otherwise mostly  
> gets out of the way.

Well, MRSP is sort of like "SDP/MRSP" -- it's the text-conferencing  
protocol, used for texting much like rtp is used for speech (although  
there's anotehr thing, real-time-text over rtp, that sometimes pops up).

So SIP is used to establish correspondence and media agreement to set  
up a media session where that media session is sent in MSRP.

There's also some work ongoing with SIP/RTSP, primarily around IPTV  
but also for surveillance.

--
Dean

---

From: [email-masked]
Date: Sat, 24 Jun 2006 18:07:28 -0400

From: Dean Willis <[email-masked]>

OK, I'm starting to grasp your point:  The question is not "Are there
ways that one can implement a private extension that will be properly
rejected/ignored by peers that do not implement the extension?" but
rather, "What are guidelines for implementing private extensions so
that they will be properly rejected/ignored by peers that do not
implement the extension?"

Which is not difficult to answer, *once people remember to ask it when
defining an extension* -- see the mechanisms I enumerated in my
previous message.

But the IETF is very good at defining protocols that are astonishingly
robust against extension...  I don't foresee trouble if people lard
all sorts of garbage into SIP, as long as they're reasonably careful.

Ah, yes.  But I note that you can define x-* Content-Dispositions as
well.  (RFC 2045 via RFC 2183 via RFC 3261!)

For that matter, we should start getting people used to defining
Content-Dispositions to describe the roles of message bodies.  Might I
suggest draft-ietf-sip-hop-limit-diagnostics-03, "Diagnostic Responses
for Session Initiation Protocol Hop Limit Errors", as a good place to
start?  It proposes a message/sipfrag body to the 483 response that
gives the contents of the failed request.  There ought to be a
Content-Disposition to explain the significance of that body.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 24 Jun 2006 20:37:26 -0400

> Content-Disposition to explain the significance of that body.

I agree there is a lot of potential in Content-Disposition. But it 
suffers from a lack  of clear specification about how it is to be used.

I have a strong suspicion that most UAs totally ignore Content-Disposition.

Question: If you send an INVITE containing an SDP body with 
Content-Disposition:render, how many will think it is an offer?

It would be a good thing to start using this for more in order to 
motivate support. But it will take awhile before it starts working 
widely. Starting by using it in something like INFO (rathere than 
INVITE) is probably a good baby step in that direction.

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Thu, 29 Jun 2006 11:27:46 +0300

Inline.

> thing ontop 'renders' it.

This may ring true for INVITE, but surely not for MESSAGE, which is
exactly the same pass'n'render concept.

> interactive communications.

I'm not sure I agree -- what do you mean by 'core sip stack'? I've
rarely seen a SIP stack that parses or interprets anything but SIP;
after all it's its primary purpose in life. It really should let others
handle 'application data'.

But for me as an application developer, I don't really care whether I
have to write:

if (strcmp(sip->method, "X-FOOBAR") == 0) {

or:

if (strcmp(sip->method, "INFO") == 0 && strcasecmp(sip->content_type,
"application/x-foobar") == 0) {

Why I reckon people are preferring the latter is because the former is
strictly not allowed. Proprietary methods are considered bad design in
SIP, and a lot of people have been saying for years you're not supposed
to use them.

This is worrying, because developers clearly want vehicles to carry
stuff like RPC; yet, SIP has not defined such a vehicle properly, and
instead seems to be saying to developers: "Go somewhere else, we don't
do that here."

Cheers,
Aki