RE: [Sip] INFO considered harmful

[Adam Roach <[e-mail]>]

The #1 issue is that the INFO RFC, today, just says,
"here's a method; do with it what you will. Everything's
allowed."

On re-reading my arguments, all I'm doing is reinforcing
this point, which I beleive is relatively uncontentious.
(Relative, that is, to...)

The more subtle point is whether to turn the free-for-all
into an organized effort that involves IANA registration,
or whether to completely close the doors.

That leads us to...

> A number of 
> drafts have proposed interoperable, non-network-crippling 
> payloads for INFO.

Okay, there's your draft, which is apparently just an informational
publication, instead of any proposal for a standard.

Beyond, that, RFC 2967 is mentioned only in the following
internet drafts:

- draft-ietf-sip-serverfeatures-05
- draft-gurbani-sin-02
  Only mention INFO as an example method

- draft-ietf-sip-message-01
  Only mentions INFO in the context of "MESSAGE has this in
  common with INFO".

- draft-ietf-sipping-sigcomp-sip-dictionary-05
  Mentions INFO because, well, it's a dictionary that includes
  all the SIP methods

- draft-garcia-sip-associated-uri-04
- draft-henrikson-sip-original-dialog-id-02
- draft-ietf-sip-join-00
- draft-ietf-sip-replaces-02
- draft-ietf-sip-callerprefs-07
  Only mention INFO in an attempt to be complete when
  expanding table 2 in RFC 3261

- draft-mahy-sipping-signaled-digits-01
  Uses INFO for RTP transport, but questions this practice
  in the open issues section

By my count, that's exactly one draft that's currently proposing
to use INFO for something nonproprietary, and even that draft isn't
so certain that INFO is the right approach.

Did I miss something?

Where are the applications that must take advantage of INFO to
work? INFO has been an RFC for over two years now, and was first
published as an ID almost four years ago. Has that been
insufficient time to come up with the killer app that makes keeping
INFO around worth the effort of updating it instead of scrapping it?

/a

> -----Original Message-----
> From: Eric Burger [mailto:[e-mail]]
> Sent: Thursday, January 09, 2003 15:34
> To: Adam Roach
> Cc: [e-mail]
> 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:[e-mail]]
> > Sent: Thursday, January 09, 2003 3:48 PM
> > To: Eric Burger; Adam Roach
> > Cc: [e-mail]
> > 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:[e-mail]]
> > > Sent: Thursday, January 09, 2003 13:37
> > > To: Adam Roach
> > > Cc: [e-mail]
> > > 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:[e-mail]]
> > > > Sent: Thursday, January 09, 2003 11:16 AM
> > > > To: 'Christer Holmberg'; Henning Schulzrinne
> > > > Cc: [e-mail]
> > > > 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 [e-mail] for questions on 
> current sip
> > > > Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip