Subject: Re: [Sip] INFO considered harmful

From: "Pete Cordell" <[email-masked]>
Date: Wed, 1 Jan 2003 11:43:45 -0000

How about we use new methods to define end-to-end application data, but name
the messages INFO-*.  e.g. INFO-MY-FEATURE, so that they can be readily
identified as application data rather than SIP state affecting methods.
Allow: can then be used to negotiate 'INFO' extensions.

- It's easy to parse.

- It's very easy for a stack to treat it generically.

- It can reuse existing SIP features to do negotiation etc.  (e.g. Allow)

- It could be easily documented in the SIP usage document.

My other thoughts on the subject (and what has led me to the above position
are):

- I think its important to have some mechanism that allows end-to-end
application data exchange that is independent of SIP state.

- Doing this in-band (rather than starting up potentially numerous side
connections) will be desirable for some applications (such as those that use
a small amounts of data).

- It seems appealing to be readily able to tell which methods affect SIP
state, and which is application level data.

- Require:, Supported: and Allow: already negotiation of features and where
possible it would be beneficial to re-use these mechanisms rather than
invent new ones..

- An INFO mechanism does not need to offer any semantics beyond simple data
delivery (although it might be nice to have an in-order delivery service?)
(and the afore mentioned negotiation).

- The main problem with INFO is that it doesn't give a single specific way
of identifying which application a particular INFO method is related to.
Hence it necessitates some sort of heuristic procedure to be used.

Some other ways to move ahead might be to:

- Specify that the application that the INFO corresponds to is defined by
the MIME type of the body.

- Define a new header that defines the application that the INFO corresponds
to.

Pete.

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: <[email-masked]>
Sent: 26 December 2002 20:12
Subject: [Sip] INFO considered harmful

> Folks,
>
> For some time, I've been complaining about the continued abuse of the
> INFO method for things that should be done other ways (frequently, not
> using sip at all). I've written up a summary of the problems and a
> proposed path forward. Specifically, I'd like to obsolete INFO and
> replace it with a spec that is approved ONLY for SIP-T.
>
> Until the I-D appears, you can pick up a version at:
>
> http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt
> http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html
>
> Thanks,
> Jonathan R.
> --
> 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

---

From: "Mark Watson" <[email-masked]>
Date: Thu, 2 Jan 2003 11:23:42 -0000

Jon,

There may be alternatives to INFO for everything in ANSI ISUP, but in ITU-T
there is the Application Transport Message (APM). The purpose of this is,
...err..., to transparently transport Application layer information.

I think any new method defined for carrying this would end up with identical
semantics to 'INFO restricted to SIP-T' as proposed in Jonathan's draft -
namely 'transport of application layer information, with the restriction
that the application layer is SIP-T'.

If you wanted to restrict its use to APM, this is something you would
restrict at the SIP-T application layer, not in SIP.

...Mark

> -----Original Message-----
> From: Peterson, Jon [mailto:[email-masked]]
> Sent: 30 December 2002 19:46
> To: 'Jonathan Rosenberg'; [email-masked]
> Subject: RE: [Sip] INFO considered harmful
> 
> 
> 
> First, I think it is a really good idea to restrict the 
> applicability of SIP
> INFO method - I very much agree with the problem defined in 
> Section 2 of
> this draft.
> 
> That much said, when it comes to solutions I am torn between 
> option number 3
> and a more radical alternative - deprecating INFO altogether. 
> While it is
> true that INFO was inspired by some of the requirements of 
> SIP-T, over time,
> we've found less and less use for INFO. The original vision 
> for SIP+ (an
> ancestor of SIP-T) relied on INFO for sending virtually every 
> ISUP message,
> but today, there just isn't that much that we do with INFO. 
> Practically
> speaking, we could probably find alternatives to INFO for 
> carrying ISUP data
> in these cases (which include SUS/RES, INF/INR, some 
> provisional response
> cases). Using INFO to send other ISUP messages is frequently 
> misguided, and
> can potentially lead to the same sorts of interoperability 
> problems we have
> with INFO in other arenas. 
> 
> Today, however, RFC3398 does allow the use of INFO in these 
> three cases, so
> it's simplest to let the INFO method to exist (option 3) for 
> the time being
> - but we should be sure to document, even for ISUP 
> transmissions, the cases
> in which it is and is not appropriate. In the long term, 
> though, I think we
> should just get rid of it entirely.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:[email-masked]]
> > Sent: Thursday, December 26, 2002 12:12 PM
> > To: [email-masked]

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 2 Jan 2003 12:34:37 -0500

What is the difference between:
	INFO-MUMBLE
	INFO-FOO

and
	MUMBLE
	FOO
???

I don't think we should go down the path of "if you method looks like INFO-%, it is special".  If you are going to parse the first few characters of the method name, you might as well parse the method name.

> From: Pete Cordell [mailto:[email-masked]]
> Sent: Wednesday, January 01, 2003 6:44 AM
> To: Jonathan Rosenberg; [email-masked]
> Subject: Re: [Sip] INFO considered harmful
> 
>

---

From: Gordon Ledgard <[email-masked]>
Date: Thu, 2 Jan 2003 13:53:45 -0500

I think people are suffering from the delusion that because SIP
has already established a channel of communication between the
transport layer of the SIP entities on the involved machines, that
it then becomes "easier" to get information to the application layer
by tunneling it through INFO on this established channel, and that 
you gain something by the "handshakes" provided "free" by SIP.

In fact, nothing at all has been gained. All of your application
connection problems remain. Michael is right in saying it provides 
no such benefit, and it makes NO difference from an app perspective,
if you tunnel junk through INFO or roll you own protocol over
another port.

Which is not to say INFO isn't useful.

  Gordon

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Thursday, January 02, 2003 12:53 PM
> To: Eric Burger
> Cc: Dean Willis; Jonathan Rosenberg; [email-masked]
> I don't get it. If you want "100% application
> specific", why not pick an unused port and roll
> your own protocol? Then all of the crufty SIPism
> don't get in the way, and the hue and cry from
> this working group ceases immediately. Do the bits 
> on the wire keep warmer if they're dressed in SIP?
> 
>        Mike
> 
> Eric Burger writes:
>  > I fully agree with Dean on this one.
>  > 
>  > One point to consider (I'm on the fence on this one) is 
> whether we would say that INFO is 100% application-specific.  
> That is, the WG will not publish standard body types.
>  > 
>  > A reason for doing that is to let people know that INFO 
> really is just, as Dean points out, 
> application-to-application communication.  If you want 
> applications to interoperate, take it either to an 
> Application Area WG or take it outside the IETF.
>  > 
>  > One reason to not do this is SIP-T should use a method 
> other than INFO.  That said, I don't think there are that 
> many SIP-T implementations extant.
>  > 
>  > 
>  > > From: Dean Willis [mailto:[email-masked]]
>  > > Sent: Tuesday, December 31, 2002 1:48 AM
>  > > To: Jonathan Rosenberg; Orit Levin
>  > > Cc: [email-masked]
>  > > At 12:48 AM 12/31/2002 -0500, Jonathan Rosenberg wrote:
>  > > >Orit Levin wrote:
>  > > >>>The big huge difference I have been trying to point out is 
>  > > that EVENTS
>  > > >>>DEFINES SEMANTICS, whereas INFO doesnt.
>  > > >>>MIME provides semantics and syntax that are independent of 
>  > > the type.
>  > > >>>SIP events provides semantics and syntax that are 
>  > > independent of the
>  > > >>>package.
>  > > >>>INFO provides nothing.
>  > > >>
>  > > >>INFO provides "minimal" but very important semantics: 
>  > > asynchronous data
>  > > >>reliably follows the established SIP path.
>  > > >
>  > > >Huh?
>  > > >
>  > > >Every new SIP method is reliable, it inherits the SIP 
>  > > transaction state 
>  > > >machine for non-invite. Follows the established path? Every 
>  > > in-dialog 
>  > > >method would have this property, it is method independent. 
>  > > >Asynchronous?  You can send any method at any time.
>  > > >
>  > > >Thus, nothing you have pointed out above is different 
>  > > between INFO and any 
>  > > >other new method we might introduce.
>  > > 
>  > > I think the key point is that there is a difference 
> between transport 
>  > > protocol semantic and application semantic. The transport 
>  > > protocol semantic 
>  > > expressed in INFO is "Here is some data that will be used by the 
>  > > application. It is not important to the transport protocol, 
>  > > except that the 
>  > > transport protocol is expected to deliver it reliably". INFO 
>  > > says NOTHING 
>  > > about the APPLICATION level semantic -- that's up to what 
>  > > goes IN the INFO 
>  > > payloads. The question is -- do we try to rigidly define 
>  > > application-level 
>  > > semantics here? Do we define that there ARE no such 
>  > > applications possible? 
>  > > Or do we design a framework by which application-level 
>  > > semantics can be 
>  > > expressed outside of the protocol definition?
>  > > 
>  > > And as for "Just add another method to your SIP stack". Let's 
>  > > say I have a 
>  > > mobile phone and the SIP stack is burned into ROM and 
> exposes only a 
>  > > simplistic transactional API. This is only likely to 
> happen, oh, 100 
>  > > million times or so over the next two years . . .  Now, just 
>  > > exactly how is 
>  > > my BREW or JTME application going to go about extending the 
>  > > SIP stack to 
>  > > support another method? Will the evil wireless operator 
>  > > networks even pass 
>  > > another method? Neither is happening anytime soon, I think . . .
>  > > 
>  > > --
>  > > Dean
>  > > 
>  > >

---

From: Adam Roach <[email-masked]>
Date: Thu, 2 Jan 2003 13:35:38 -0600

The argument of "but I'm already holding a hammer and *want*
to treat everything like a nail!" comes up on about an annual
basis, and is rejected outright each time.

Just because you have a SIP stack in your application does
*not* mean that it is appropriate to use that stack for
all general network access. You're allowing laziness to
overwhelm good application design.

/a

> From: George Foti (LMC) [mailto:[email-masked]]
> Sent: Thursday, January 02, 2003 12:55
> To: 'Michael Thomas'; Eric Burger
> The application is SIP based, we dont need yet another 
> protocol to convey what needs to be conveyed e2e.
> No need to go around the bush.
> Lets find *real* arguments against using INFO for that 
> purpopse rather than philosphical  ones.
> 
> /gf
> 
> 
> 
>

---

From: "George Foti (LMC)" <[email-masked]>
Date: Thu, 2 Jan 2003 17:04:42 -0500

This should not be a philosophical discusion.
If a new SIP method is okay, why is INFO not okay.

What is the difference?
Please explain in technical terms?

/gf

-----Original Message-----
From: Adam Roach [mailto:[email-masked]]
Sent: Thursday, January 02, 2003 2:36 PM
To: 'George Foti (LMC)'; 'Michael Thomas'; Eric Burger
Cc: Dean Willis; Jonathan Rosenberg; [email-masked]
Subject: RE: [Sip] INFO considered harmful

/a

---

From: "George Foti (LMC)" <[email-masked]>
Date: Thu, 2 Jan 2003 19:10:19 -0500

>I could go on, but this topic has had extensive airing on
>the list in years past. There's really no reason to beat
>this particular dead horse any longer.

Agreed, but the extremety, the exaggarations and the imaginary, creative non-real abuses and comparisons with other protocols, that have been raised on e-mails about misuse of INFO represents a *sad* distortion of how most common sense people have used it, and contradicts the reality on the ground.
Only constructive counter proposals may move this forward.  

Rgds/gf

-----Original Message-----
From: Adam Roach [mailto:[email-masked]]
Sent: Thursday, January 02, 2003 5:57 PM
To: 'George Foti (LMC)'; Adam Roach; 'Michael Thomas'; Eric Burger
Cc: Dean Willis; Jonathan Rosenberg; [email-masked]
Subject: RE: [Sip] INFO considered harmful

A new method would be okay for new SIP-related functionality.

But that's not what you proposed.

You said, "The application is SIP based, we dont need yet
another protocol to convey what needs to be conveyed e2e,"
which is an argument that we should use SIP as a general
purpose RPC mechanism for any application that already has
a SIP stack.

Doing what you propose with INFO is inappropriate.

Doing what you propose with a new method is inappropriate.

Doing what you propose with SIP is inappropriate.

Since you keep harping on technical, as opposed to
philosophical, arguments, here's a couple:

  - The SIP protocol was designed for session initiation,
    negotiation, and teardown. The timing characteristics
    are not generally appropriate for application control.
    For example, with typical SIP networks, latency and
    jitter of messages are too high to provide any sort
    of reasonable user experience for floor control
    or DTMF transport.

 - Many proxies stay in the signalling path for the purposes
   of providing services. By sending unnecessary application-
   level information throught these proxies, you reduce the
   capacity and increase possible congestion of the network.

I could go on, but this topic has had extensive airing on
the list in years past. There's really no reason to beat
this particular dead horse any longer.

/a

> Sent: Thursday, January 02, 2003 16:05
> To: 'Adam Roach'; George Foti (LMC); 'Michael Thomas'; Eric Burger

---

From: Adam Roach <[email-masked]>
Date: Thu, 2 Jan 2003 18:15:00 -0600

> Agreed, but the extremety, the exaggarations and the 
> imaginary, creative non-real abuses and comparisons with 
> other protocols, that have been raised on e-mails about 
> misuse of INFO represents a *sad* distortion of how most 
> common sense people have used it, and contradicts the reality 
> on the ground.

Imaginary? Non-real?

Ummm... "DTMF Transport" and "Floor Control" are the two
examples I offered as being inappropriate (along with
a good, technical explanation of why). Both of these have
been seriously suggested as standard extensions to SIP.

I've even seen attempts to deploy them. In a real
carrier environment. End result: scrapping that part
of the system and going back to the drawing board.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 2 Jan 2003 19:07:54 -0600

> From: Frank W. Miller [mailto:[email-masked]]
>
> What I'm referring to is the need for implementors to build 
> upon the basic signaling mechanism that SIP provides.  If an
> application has signaling needs that are not met with the basic
> protocol constructs, application implementors need a way to make
> it happen. As others have argued, there are instances where
> augmenting the (perhaps third party) SIP stack source code with
> new methods does not make sense.

Sorry for being a bit obtuse (and sarcastic). I was trying to
grab your attention, since the earlier statement (made by Jonathan)
that one should use SIP to initiate such sessions apparently failed
to do so.

I wasn't proposing adding new methods. I was proposing using INVITE to
establish a session, and exchanging your application-level information
using such a session.

> This can be expensive and
> time-consuming compared to say, punting an INFO body written in
> XML to an open source parser. The ability to get something
> like this done quickly and/or without perturbing the SIP stack
> code is very important, despite your sarcasm.

Shoving XML over TCP (perhaps using SOAP, if that suits
your fancy) is trivial to code, and the comedia extensions
make it possible. It is all eminently expresible using SDP
as it exists today, and, for any decent programmer with the
most basic understanding of sockets programming (or even a
good abstraction library), is every bit as easy as what you
propose.

Except, of course, that it lacks the "SIP as general-purpose
RPC" abuse factor.

/a

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 3 Jan 2003 16:20:25 -0000

And I will support that.

There may be a place for session based messaging, but for all those uses where cellphone SMS constraints work today, MESSAGE seems to be the appropriate solution.

By the way, when we do get session based messaging, it will probably be impossible to write scoping rules that prevent someone sending two MESSAGE requests to the same destination, rather than setting up a session and sending two PDUs within that session. All we will be able to do is provide guidance.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> Sent: 03 January 2003 06:19
> To: Henning Schulzrinne
> Cc: Adam Roach; 'Neil Deason'; [email-masked]
> Henning is dead on.
> I think we will always need MESSAGE for this reason exactly. 
> It may be, 
> that as messaging sessions are completed, and we understand 
> the problem 
> space better, we would revise MESSAGE to impose further 
> restrictions on 
> it. For now, I think its pretty good as written.
> 
> -Jonathan R.
> 
> Henning Schulzrinne wrote:
> > Actually, there's an important difference: MESSAGE can use the SIP 
> > features outside an established session, while INFO is 
> within a session 
> > (and thus there are other SDP-negotiated, options 
> available). Within a 
> > session, the only real reason for a follow-the-INVITE SIP 
> message is 
> > that a direct IP-level connection can't be made to work.
> > 
> >  From an efficiency standpoint, if you only have very occasional 
> > messages, you gain by a "connectionless" approach. After 
> all, an INVITE 
> > transaction for a single MESSAGE doesn't buy you much and doesn't 
> > conserve the oh-so-precious proxy cycles. While such short 
> sessions are 
> > probably not common for human-to-human communication 
> (except spam...), 
> > they may well be common for the type of things that SMS and 
> pagers are 
> > popular for: machine-to-human or machine-to-machine communications 
> > announcing infrequent and unpredictable events ("your flight is now 
> > leaving on gate 37", "your FedEx just arrived", "Server 42 
> is on fire").
> > 
> > Adam Roach wrote:
> > 
> >>> From: Neil Deason [mailto:[email-masked]]
> >>>
> >>> Actually if we want to police protocol usage closely we 
> had better 
> >>> look at deprecating MESSAGE too.
> >>
> >>
> >>
> >> Come back when SIMPLE has finished defining the message sessions,
> >> and I'll throw my voice behind yours in advocating this.
> >>
> >> /a

---

From: Adam Roach <[email-masked]>
Date: Tue, 7 Jan 2003 17:09:23 -0600

Sorry for being pedantic, but under the circumstances you
describe, it would cause far less confusion and help
limit disinformation if you were to phrase such things
as "The main issue with our proprietary use of SIP-T..."

Your original statement asserted (presumably unintentionally)
that using SIP-T *requires* SIP proxies to understand ISUP,
which is clearly not true.

/a

P.S. The expensive part of your ISUP stacks is not the encoding;
     it's the state machines. The syntactical transformation you
     propose actually gains you very little. ISUP encoding is
     delightfully simple to code. In fact, five years ago, I could
     do it in my head for the most common operations.

> Sent: Tuesday, January 07, 2003 16:37
> To: Adam Roach
> Cc: [email-masked]
> I'm not talking about how it was intended for use, I'm 
> talking about how it
> can and is being used in some instances (seems to be a theme 
> here lately).
> 
> FM
> 
> 
> From: "Adam Roach" <[email-masked]>
> To: "'Frank W. Miller'" <[email-masked]>; "Mark Watson"
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, January 07, 2003 2:44 PM
> > > The main issue with SIP-T is that it requires some portion
> > > of the SS7 stack to be present in the IP elements of the network.
> >
> > Huh?
> >
> > I beleive you've completely misunderstood the purpose of SIP-T.
> > If you have an IP element (pure IP, not your gateway) that's
> > interpreting the ISUP bodies present in SIP-T messages, you're
> > violating the spirit of what was intended.
> >
> 
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 8 Jan 2003 11:02:53 -0500

I don't know if there is a relationship, but Cisco brought just such a
text-encoding proposal to ITU-T Study Group 11.  I very much agree that if
this proposal goes forward, it should use XML rather than some arbitrary
TL-1-like language.

> Sent: Friday, January 03, 2003 7:02 PM
> To: Dean Willis
> Cc: [email-masked]
> Well, any illusion of reasonableness I may have garnered in 
> the past is about to be shattered.  I would refer folks to:
> 
> http://www.ietf.org/internet-drafts/draft-miller-sip-isup-annex-00.txt
> 
> This draft is about to receive a major -01 update that 
> recodes the entire syntax in XML.  In addition, we (I) have 
> another draft that does something very similar for ANSI TCAP 
> that I'll be submitting in short order.  I guess its only 
> appropriate that I bring peoples attention to these drafts 
> under the current subject heading...
> 
> FM
> 
> Frank W. Miller, Ph.D.
> Chief Technical Officer
> sentitO Networks, Inc.
> [email-masked]
> 
> From: "Dean Willis" <[email-masked]>
> To: "'Neil Deason'" <[email-masked]>; "'Adam Roach'" 
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, January 03, 2003 6:13 PM
> > > What I was actually advocating here was ppl wanting to keep INFO 
> > > around write up something to illuminate INFO packages and provide 
> > > example usage.
> > >
> > > The MESSAGE cf INFO was just an attempt to highlight an apparent 
> > > limitation with the ban INFO approach. Every MIME type in an INFO 
> > > can be moved into MESSAGE rather than go away. Maybe through 
> > > exploring INFO packages we evolve the collective 
> understanding that 
> > > this is/isn't a necessary thing.
> > >
> > > Cheers,
> > > Neil.
> >
> > This is an excellent suggestion, and very similar to the 
> one Jonathan 
> > made to me on the phone yesterday (actually, I think he 
> more tersely 
> > worded it
> as
> > "Send Text!")
> >
> > --
> > Dean
> >
> > Use [email-masked] for questions on 
> current sip Use 
> > [email-masked] for new developments on the application of sip
> >
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
>

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 9 Jan 2003 10:50:17 -0000

Maybe Adam wrote the original slightly stronger than I would, but the NOTIFY method itself does carry semantics.

Those semantics are that it is carrying information defined as an event. Obviously you need to read the relevant headers and the body to find out what sort of event, but until you read the string "NOTIFY" at the start of the received PDU, you do not know you are looking for an event.

Obviously there are also normative requirements to understanding how it fits in a dialog, but I agree, that is part of the protocol specification rather than semantics of the method.

As such it is not carried unstructured information (INFO), or information defined as fulfilling instant messaging requirements (MESSAGE).

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> Sent: 08 January 2003 22:55
> To: 'Jonathan Rosenberg'
> Cc: [email-masked]
> > > No, EVENTS doesn't define semantics.
> > 
> > Of course it does. There are lots of MAYS, MUSTS and SHOULDs 
> > in there. 
> > There is behavior dealing with subscription refreshes, rules 
> > on when to 
> > send NOTIFY, and so on and so on. How can you say that none 
> of those 
> > qualify as semantics?
> 
> 
> That's called a "protocol specification", not a specification of the
> semanticsd of the delivered content.
> 
> What does a NOTIFY mean? Does it mean that I have voice mail 
> and I should
> poll it? Does it mean that somebody has subscribed to my 
> presence and I
> should adjust my authorization policy? Does it mean that my 
> laundry is done
> and I should go pick it up? Does it mean that the IRS is 
> going to audit my
> books and I should flee for the border?  
> 
> You can't answer this question, in general, because those 
> semantics are NOT
> defined in RFC 3265. They're defined in event packages.
> 
> Similarly, we complain because the INFO spec doen't tell us 
> what an INFO
> means. Should we convert the body to ISUP? Should we execute 
> the operator
> now? Should the phone explode? The INFO spec should no more 
> answer this than
> does the Events spec. The semantic encoding is a separate problem.
> 
> Now, here's the difference. I don't think you're talking 
> about the presence
> of semantic information. I think you're talking about the absence of a
> mechanism for documenting the semantic information. Event 
> packages give us
> this mechanism for events. We don't have anything like that 
> for INFO. You're
> not talking semantics -- you're talking tools for exchanging 
> meta-semantics.
> 
> > 
> > > Event PACKAGES define the semantics of
> > > particular instances of the event methods.
> > 
> > Within a well defined framework. 3265 defines clear rules on 
> > what each 
> > package has to specify, and what it can and cannot due ontop 
> > of rfc3265.
> > 
> > 
> > > INFO also needs a blob-describing-and-encoding framework, 
> > so that the 
> > > various uses of INFO can, as appropriate, be effectively 
> documented 
> > > and negotiated.
> > 
> > Well, I'll try one more time, since I am clearly not 
> getting my point 
> > across.
> > 
> > RFC3265 defines semantics above and beyond RFC3261. All of those 
> > MAY/MUST/SHOULD I was talking about. If you had a choice between 
> > defining a new package, and defining your own sub/not 
> mechanisms, it 
> > would be a LOT more work to define your own sub/not mechanisms.
> 
> huh?
> 
> It would be much more work to independently reimplement the 
> functionality of
> INFO than it is to encode some information into MIME and ship 
> it via INFO,
> especially given that the main functionality of INFO is correlated
> resolution with an existing dialog (identical rendezvous).
> 
> > Not so for INFO. WHen deciding whether to specify an INFO 
> usage, or a 
> > new method, there is no additional work to do 
> > (specification-wise) when 
> > specifying a new method as opposed to a new INFO usage. To me, that 
> > means that INFO is devoid of semantics.
> 
> No, it just means that the process for defining a new INFO 
> usage is broken.
> 
> --
> Dean
>

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 9 Jan 2003 14:36:48 -0500

Funny, none of the existing uses of INFO has melted the network.

Counterexamples?

> Sent: Thursday, January 09, 2003 11:16 AM
> To: 'Christer Holmberg'; Henning Schulzrinne
> Cc: [email-masked]
> > 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

---

From: Adam Roach <[email-masked]>
Date: Thu, 9 Jan 2003 14:47:48 -0600

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

> From: Eric Burger [mailto:[email-masked]]
> Sent: Thursday, January 09, 2003 13:37
> To: Adam Roach
> Cc: [email-masked]

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 9 Jan 2003 16:34:17 -0500

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 :-)

> Sent: Thursday, January 09, 2003 3:48 PM
> To: Eric Burger; Adam Roach
> Cc: [email-masked]

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 10 Jan 2003 08:45:56 -0600

Hi all,

Typically wanting to avoid these types of debate, I thought I  would just
respond to this one point in Jon's posting (I've deleted the rest of the
thread), which I think gets to the crux of the primary concern.

----beginning of thread snipped----

>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?

----rest of thread deleted-----

I think the initial reaction and what folks were originally most concerned
over was the deprecation of the use of INFO (for other than SIP-T), which
was the preferred approach identified in Jonathan's draft.  I would think
that most people would not object to some guidelines around the use of INFO,
although I would think many would be more in favor of a 1.5 versus the
"completeness" proposed by the second approach in the draft. Basically, I'm
suggesting providing a venue (i.e. as part of SIPPING WG charter, perhaps)
to review individual usages of INFO.  The reality is that if you want your
use of INFO to interwork with a 3rd party, some level of specification is
required and in the end some of the usages might indeed converge to a widely
deployed approach or perhaps put the spotlight on the need for a new method.

As others have suggested, deprecating INFO or being too stringent in
enforcing it's usage would likely move the policing of the protocol problem
elsewhere, perhaps where the guidelines are less stringent (e.g. the lack of
registration with IANA is only discouraged).  And, as others have said the
"bad" guys will likely to continue using it regardless (not caring that it
impacts their particular "seal of IETF approval"). 

Regards,
Mary H. Barnes
[email-masked]

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 10 Jan 2003 15:20:38 -0000

Perhaps it would be appropriate to have the same review mechanism and restrictions on INFO usage as provided for P-headers and event definitions. 

If the sip changes draft is still active, maybe we need some text in there. 

There would additionally need to be some text in the sip guidelines document.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> From: Mary Barnes [mailto:[email-masked]]
> Sent: 10 January 2003 14:46
> To: 'Peterson, Jon'; 'Eric Burger'; Adam Roach
> Cc: [email-masked]

---

From: Adam Roach <[email-masked]>
Date: Fri, 10 Jan 2003 13:02:00 -0600

> It's deliberate, and they're doing it just to spite you (Adam).
> In fact, if you check the phone on your desk that you use every
> day, I'll bet you find that it's committing the heresy of DTMF-INFO
> on every dialed call.

Just checked. AVT tones payload, actually.

/a