Subject: RE: [Sip] INFO considered harmful

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 9 Jan 2003 18:04:57 -0500

Comparing the projected use of SIP INFO with UDP is very apt. However, we
already have a UDP, and we don't need SIP to become a more cumbersome
surrogate.

This argument has gone around and around to little profit. There is no
question that SIP can be used as a transport protocol, and we cannot prevent
implementers from doing that. Indeed, any protocol can be misapplied. The
real argument here is just about what the specifications should present as
the correct application of the protocol.

While you can argue, Eric, that SIP has lost sight of its original goals,
and therefore that it doesn't matter what ugliness we introduce now, I
disagree. There are two functions that SIP is intended to provide -
discovery and session management. Generic data delivery is not one of these
functions. Your arguments that SIP is bloated, or what have you, would
encourage us to reduce the scope of the standard, not to condone mistakes
that clearly conflict with SIP's mission.

I also do not agree that SIP needs any method that is designed for
experimentation. You are welcome to implement any experiments you would like
- but the standard does not need to detail any particular way of
experimenting with SIP in order to enable you to do so. If we did believe
this was necessary, we could create an EXPERIMENTAL method - clearly, we
chose not to give INFO that name for some reason. We do not need to
standardize a method for experimentation because standards exist to foster
interoperability - experiments will necessarily run between experimental
user agents that do not need a standard specification describing their
experimental behavior.

It is hard for me to understand why the unregulated use of INFO is being
defended so vehemently. A correction to INFO that regulated its usage, and
provided some guidelines for what can legitimately be standardized as uses
of the INFO method, would be a big improvement over what we have now, and it
would not conflict with any future appropriate use of the method. Is even
that being rejected here?

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: Thursday, January 09, 2003 1:34 PM
> To: Adam Roach
> Cc: [email-masked]
> Subject: RE: [Sip] INFO considered harmful
> 
> 
> I guess the rat hole is "noninteroperable, potentially 
> network-crippling approaches credibility."  A number of 
> drafts have proposed interoperable, non-network-crippling 
> payloads for INFO.
> 
> Rewind 20 years.  Replace INFO with UDP.  The arguments are 
> IDENTICAL.  Unless you want to keep X.25 alive, who today 
> would live without UDP?  RTP would be bumming :-)
> 
> > -----Original Message-----
> > From: Adam Roach [mailto:[email-masked]]
> > Sent: Thursday, January 09, 2003 3:48 PM
> > To: Eric Burger; Adam Roach
> > Cc: [email-masked]
> > Subject: RE: [Sip] INFO considered harmful
> > 
> > 
> > I said "potentially network-crippling," for the exact reason
> > that I don't have examples of this happening specifically
> > with SIP. What I do have, as I've cited before, is examples
> > of the whacked-out kind of things that people will do and
> > have done to appliation-level protocols. The potential exists,
> > and there is a demonstrated will to exploit it.
> > 
> > I'll repeat the example here.
> > 
> > I'm recalling the rise in popularity of Real Media Player and
> > its ability to set up an audio stream through an HTTP proxy.
> > In particular, I'm recalling conversations shortly thereafter
> > with some friends over in MIS about how they just couldn't add
> > capacity to the HTTP proxy pool fast enough to keep up with
> > demand.
> > 
> > Access to external web documents sometimes creeped up to the
> > order of minutes before everything was finally stabilized.
> > It would be difficult to argue that such a mode of operation
> > represents anything other than a crippled network.
> > 
> > How long do you guess it will be before Real player
> > (or a similar product) includes a "SIP Proxy:" field right
> > next to its "HTTP Proxy:" field for firewall circumvention?
> > 
> > And, lest we lose sight of why I'm saying this in the
> > first place (this conversation has shown signs of extreme
> > ADHD): Yes, people *will* abuse the protocol. There's
> > nothing we can do about that simple fact. It is, however,
> > irresponsible for the IETF to lend these noninteroperable,
> > potentially network-crippling approaches credibility.
> > 
> > /a
> > 
> > > -----Original Message-----
> > > From: Eric Burger [mailto:[email-masked]]
> > > Sent: Thursday, January 09, 2003 13:37
> > > To: Adam Roach
> > > Cc: [email-masked]
> > > Subject: RE: [Sip] INFO considered harmful
> > > 
> > > 
> > > Funny, none of the existing uses of INFO has melted the network.
> > > 
> > > Counterexamples?
> > > 
> > > > -----Original Message-----
> > > > From: Adam Roach [mailto:[email-masked]]
> > > > Sent: Thursday, January 09, 2003 11:16 AM
> > > > To: 'Christer Holmberg'; Henning Schulzrinne
> > > > Cc: [email-masked]
> > > > Subject: RE: [Sip] INFO considered harmful
> > > > 
> > > > 
> > > > > If that is the solution, I see no reason for this whole 
> > > > > thread :) There is no idea to put any restrictions on INFO
> > > > > either, because the bad guys will ignore it anyway...
> > > > 
> > > > Yes, people will do it. Unless we take up arms and 
> start a massive
> > > > intelligence effort, there's nothing we can do about that simple
> > > > fact.
> > > > 
> > > > The overarching question is: should the IETF lend these
> > > > noninteroperable, potentially network-crippling approaches
> > > > credibility? Allison? Does the IESG generally condone that
> > > > sort of thing?
> > > > 
> > > > /a
> > > > _______________________________________________
> > > > 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
> 
_______________________________________________
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: "Dean Willis" <[email-masked]>
Date: Thu, 9 Jan 2003 18:13:49 -0600

> Jon says:
> There are two 
> functions that SIP is intended to provide - discovery and 
> session management. Generic data delivery is not one of these 
> functions. 

Perhaps you overlook the "rendezvous" function, which is not quite the same
as "discovery". The utility of INFO is that it delivers data to the
endpoints of a specific dialog, while respecting the SIP-level anonymity,
security, and routing functionality of that dialog. Nothing BUT an in-dialog
SIP method has that property, as we discovered in the extended discssion of
binding HTTP URLS to SIP.

> It is hard for me to understand why the unregulated use of 
> INFO is being defended so vehemently. A correction to INFO 
> that regulated its usage, and provided some guidelines for 
> what can legitimately be standardized as uses of the INFO 
> method, would be a big improvement over what we have now, and 
> it would not conflict with any future appropriate use of the 
> method. Is even that being rejected here?

No, what's being rejected out-of-hand is the notion that INFO is horribly
dangerous and busily eating the internet like a giant space-amoeba,
requiring us immediately to allocate resources to expurgate it. I suspect
that the participants are simply enjoying the debate, much as my dog enjoys
chewing a piece of rawhide.

There is probably an undercurrent of debate on exactly what sorts of
constraints, guidances, and registrations should be applied, but that
discussion could probably be readily diverteed into a "send text"
instruction.

--
Dean