Subject: RE: [Sip] Re: Restatement: INFO considered harmful

From: "Eric Burger" <[email-masked]>
Date: Mon, 6 Jan 2003 10:33:38 -0500

I actually think the lines are that black and white.

Said differently, we now have three years of experience with SIP.  There's been a lot of pulling and stretching that has made the vision of a simple, text-based protocol for initiating multimedia sessions a lost dream.

A serious question is, "Which has more pages, H.323 et. al. or RFC 3261 et. al.?".

Reading Dean's posting, I was thinking, "It is time for SIP 3.0".  For that matter, for marketing reasons, it would need a different name.  A much simpler protocol that does one thing well (the IETF mantra) would NOT be backwards compatible with the bloat that we have today.

I don't think there is a middle ground.  To mix my metaphors, The line in the sand is being washed away by the tide of features.  Now that we have brushed away the session initiation simplicity (e.g., REGISTER, MESSAGE, SUBSCRIBE, NOTIFY, INFO), I cannot see how one can, with a straight face, say, "My child is cute, but your child is ugly" [substitute method/body for child].

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, January 03, 2003 5:44 PM
> To: Dean Willis
> Cc: 'Adam Roach'; 'Frank W. Miller'; [email-masked]
> Subject: [Sip] Re: Restatement: INFO considered harmful
> 
> 
> Dean,
> 
> The lines are not always so black and white. Its not a choice between 
> "do anything" and "do nothing but INVITE". There is a line somewhere 
> about what is a good use of sip, and what is not. We have some 
> documents, even, which help to identify that line (SIP 
> guidelines), and 
> no doubt it has moved over time. Indeed, there were even 
> arguments about 
> whether BYE belonged in SIP, since clearly its not needed for 
> "initiation". However, if you buy the assertion that SIP needs to at 
> least manage the session, that clearly includes termination 
> as well as 
> initiation. These days, I know of very few folks (only one in 
> fact) that 
> would argue against BYE as part of SIP.
> 
> I still stand by my assertion that many of the usages of SIP INFO are 
> over that line, and that in order to keep the usages in a line we are 
> comfortable with, something has to be done.
> 
> -Jonathan R.
> 
> Dean Willis wrote:
> > My mother said I should stop inflaming things, but here I 
> go again anyhow.
> > Sorry, Mom.
> > 
> > Adam said, responding to Frank in our long-winded exchange:
> > 
> >>Perhaps using some sort of protocol to initate this session 
> >>would be appropriate. You'll also needs a protocol of some 
> >>sort to describe it, probably carried as a payload in this 
> >>session initation protocol. Ideally, this session description 
> >>protocol could leverage IANA-registered media types to 
> >>describe the content of such sessions, so that an infinite 
> >>number of types of sessions can be described.
> > 
> > 
> > Actually, Adam and I just had a conversation about this 
> argument. I think
> > actually that there is something hiding in here which is 
> THE HEART of almost
> > every philosophical debate we've ever had in SIP. If we can 
> get this nailed
> > down now, we'll be preventing a HUGE number of future fights.
> > 
> > Or in short: Boom! Epiphany! I think I understand what 
> we're arguing about.
> > 
> > I'll admit -- Adam's been philosophically consistent in his 
> arguments since
> > day 1.  He believes that SIP should start sessions, stop 
> sessions, and
> > nothing else.
> > 
> > Examples:
> > 
> > Lets look at "events". By Adam's logic, the event system 
> should consist of
> > sending an INVITE (instead of a SUBSCRIBE) to the event 
> source. The SDP body
> > (Only SDP should be allowed in INVITE) would descibe the 
> events being
> > requested and the protocol, IP address and port number on which the
> > subscriber would be listening. The 200 OK response from the 
> event source
> > would then contain the protocol, IP address and port number 
> to which the
> > subscriber should send acknowledgements of notifications, 
> assuming that the
> > notification-transport protocol (clearly, not SIP).
> > 
> > And Whoa! Look at REGISTER. That doesn't set up any kind of 
> session! It's
> > clearly not a SIP function. We should instead use an INVITE 
> to set up a
> > "registration session", over which we would then use a 
> registration protocol
> > to establish registrations.
> > 
> > MESSAGE is clearly divergent. By Adam's logic, only message 
> sessions should
> > be used. By similar reasoning, INFO is also off, and 
> instead SIP-T should
> > use INVITE to establish a sigtran session.
> > 
> > This actually all makes sense and hangs together philosophically.
> > 
> > The problem is, the working group diverted from that 
> philosophy a long time
> > ago. What we have now is a combination of three 
> transactional protocols
> > (REGISTER, OPTIONS, MESSAGE) with a session-establishment 
> protocol (INVITE)
> > which supports several in-session request verbs (UPDATE, 
> OPTIONS, ACK, INFO,
> > MESSAGE, BYE, PRACK, etc.) and another 
> session-establishment protocol
> > (SUBSCRIBE) which supports an in-session request verb 
> (NOTIFY). We've also
> > defined an intermediation framework (the SIP Proxy) and a 
> set of end-to-end
> > and hop-by-hop authentication and integrity protection 
> mechanisms that can
> > be used for all these protocols. Really, it's the 
> intermediation framework
> > that gives SIP most of its utility.
> > 
> > Ok, it could be tidier. But it is very powerful, fairly 
> complete, and
> > actually works. And yes, the combination effectively 
> provides a very useful
> > transport protocol that does all sorts of things that HTTP 
> alone can't do,
> > such as intermediated rendezvous. And no, it DOESN'T just 
> do phone calls
> > (making attempts to model proxy load based on telephone 
> switch metrics
> > hopelessly bogus).
> > 
> > So my humble suggestion: Get over it. Iron out any kruft 
> that makes SIP less
> > desirable as a transport protocol (like UDP), and get on 
> with the business
> > of making stuff that people can use to get their jobs done. 
> Stop complaining
> > that your proxies are getting loaded down by serving a 
> useful purpose to
> > somebody, and start understanding what that purpose is and 
> how to charge for
> > it.
> > 
> > If you don't like it, fine. Let's take out a poll on 
> deprecating REGISTER,
> > MESSAGE, SUBSCRIBE, INFO, PRACK, SUBSCRIBE, NOTIFY, and all 
> that other
> > stuff.
> > 
> > Or hey, just toss it all out and add session negotiation to XMPP. 
> > 
> > --
> > Dean
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> 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
> 
_______________________________________________
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