Subject: RE: [Sip] Additional uses of INFO

From: "James M. Polk" <[email-masked]>
Date: Wed, 14 Jun 2006 11:56:05 -0500

At 05:26 PM 6/14/2006 +0100, Drage, Keith (Keith) wrote:
>Unfortunately you never pushed this through to an RFC, so the WG never 
>formed a consensus opinion one way or the other.
>
>What we have is therefore people referring to the INFO RFC and thinking 
>they can use it for everything.
>
>What you appear to be saying from your viewpoint is to update something to 
>say either
>
>-       No usage outside existing ISUP usage; or
>-       Additional usages are RFC required, so that those usages can have 
>expert review for the harm to the SIP environment.

Hitchiker's states:

         "It defines a method, INFO, used to transport
         mid-dialog information that has no impact on
         SIP itself."

This means no impact on SIP, so why would a review be required - unless you 
want a review that there is no harm caused to SIP.

>Is this right or is there another view?
>
>regards
>
>Keith
>
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:[email-masked]]
> > Sent: 14 June 2006 17:03
> > To: Drage, Keith (Keith)
> > Cc: [email-masked]
> > Subject: Re: [Sip] Additional uses of INFO
> >
> >
> > Well, my opinion on INFO is that its an exceptionally poor vehicle for
> > doing extensions. A long while back, I wrote an I-D called "INFO
> > considered harmful" which summarized my thinking on this:
> >
> > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt
> >
> > The conclusion of the document is that we should limit INFO
> > to its only
> > defined usage - for ISUP transport - and I still think this
> > conclusion
> > makes sense.
> >
> > Thanks,
> > Jonathan R.
> >
> > Drage, Keith (Keith) wrote:
> >
> > > Within the SIP protocol we have done a lot of tidying up as to how
> > > extensions are made to the SIP protocol.
> > >
> > > In particular RFC 3968 and RFC 3969 set up various
> > registries for the
> > > session initiation protocol, and RFC 3427 defines rules for
> > > definition of headers and event packages.
> > >
> > > Both within IETF, and in discussions outside IETF, we still see
> > > proposals to use the INFO method (RFC 2976) for various
> > purposes, and
> > > we have no really clear statements on whether INFO method can be
> > > applied to new applications, or not, and if so, who should document
> > > those new applications. This is probably complicated by the
> > fact that
> > > the INFO RFC
> > >
> > >
> > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-hitchh
> > ikers-guide-00.txt
> > > currently lists RFC 2976 under the PSTN interworking specifications,
> > > and that is currently the only defined IETF usage, and also
> > indicates
> > > under the general infrastructure section:
> > >
> > > RFC 2976: The INFO Method (S) RFC 2976 [39] was defined as an
> > > extension to RFC 2543.  It defines a method, INFO, used to transport
> > > mid-dialog information that has no impact on SIP itself. Its driving
> > > application was the transport of PSTN related information when using
> > > SIP between a pair of gateways.  Though originally conceived for
> > > broader use, it only found standardized usage with SIP-T [33].  It
> > > has been used to support numerous proprietary and non-interoperable
> > > extensions due to its poorly defined scope.
> > >
> > > My question is whether it is appropriate to provide some means of
> > > clarifying other usages of the INFO method, and who should document
> > > them. Should that occur in:
> > >
> > > i)  An update or revision to RFC 2976 ii)   An update to
> > RFC 3427 iii)
> > > Anywhere else
> > >
> > > regards
> > >
> > > Keith
> > >
> > > Keith Drage [email-masked] tel: +44 1793 776249
> > >
> > > _______________________________________________ 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
> > >
> >
> > --
> > 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
> >
>
>_______________________________________________
>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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Jun 2006 16:42:56 -0400

The problem is that this 'no impact on SIP' is really quite meaningless. 
   Does it mean the dialog state? Does it mean that it is always passed 
to a human user? Considering dialog state for example, we have methods 
that have no impact on the SIP dialog states (such as MESSAGE), yet we 
have chosen (correctly I think) to define methods for them.

The reality is that, one way or another, you need to define 
specifications that allow entity A to send information to entity B if 
you expect it to be processed by an automata. I'm suggesting that, if 
the protocol used to transport that information is SIP, we have several 
defined techniques for extensibility (new method, body, params, etc.) 
which are sufficient. I see no need for a *new* extensibility vehicle.

Thanks,
Jonathan R.

James M. Polk wrote:

>> What we have is therefore people referring to the INFO RFC and 
>> thinking they can use it for everything.
>>
>> What you appear to be saying from your viewpoint is to update 
>> something to say either
>>
>> -       Additional usages are RFC required, so that those usages can 
>> have expert review for the harm to the SIP environment.
> 
> 
> Hitchiker's states:
> 
> This means no impact on SIP, so why would a review be required - unless 
> you want a review that there is no harm caused to SIP.
> 
> 

-- 
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: Wed, 14 Jun 2006 22:53:23 -0500

On Jun 14, 2006, at 3:42 PM, Jonathan Rosenberg wrote:

> The problem is that this 'no impact on SIP' is really quite  
> meaningless.   Does it mean the dialog state? Does it mean that it  
> is always passed to a human user? Considering dialog state for  
> example, we have methods that have no impact on the SIP dialog  
> states (such as MESSAGE), yet we have chosen (correctly I think) to  
> define methods for them.
>
> specifications that allow entity A to send information to entity B  
> if you expect it to be processed by an automata. I'm suggesting  
> that, if the protocol used to transport that information is SIP, we  
> have several defined techniques for extensibility (new method,  
> body, params, etc.) which are sufficient. I see no need for a *new*  
> extensibility vehicle.

And, as always, I see no good reason to keep changing the core  
protocol, adding stuff to parsers, B2BUAs, and so on, just to pass  
hunks of data that do not, in and of themselves, interact with the  
SIP state machine.

MESSAGE is INFO, except that INFO is supposedly always in a dialog  
(it doesn't really have to be) whereas as MESSAGE could be but really  
sortof is not supposed to be, and MESSAGE is supposedly always  
presented to the user (which we know is not true in practice).  
Personally, I'd suggest unifying the two with a stronger explication  
of content-disposition and be done with it. I think the "info  
package" model gives us that stronger explication.

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.

Now, there is a reason (albeit possibly not "good") to keep extending  
SIP willy-illy. That is, we've already got so many half-baked, sort- 
of-overlapping extensions that making the protocol properly layered  
for transport just isn't going to happen, so we might as well keep  
adding stuff the way we've been doing it. It may well be true that  
changing horses (or extension methodology) in midstream will do more  
harm than good.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 20 Jun 2006 19:44:15 -0700

On Jun 14, 2006, at 8:53 PM, Dean Willis wrote:

> type of image file or to build a new type of web application? Let  
> me think . . . nope, we don't.

Clearly some applications fit inside the extensibility model that  
HTTP had - others, such as webdav, caldav, atom may not change HTTP  
but were some pretty serious extensions - and Don't even ask about  
how ETag works consistently across all theses.

Back to the topics of SIP ... I have not gone and read the various  
drafts on this but it seems like we have some recommendation on how  
to extend SIP (RFC 4485). Now I'm sure eventually things will come up  
where this is not enough but discussing it in the abstract is pretty  
hard. I'd rather not build new extensibility mechanisms until we saw  
some things that would use them - I'd be very afraid whatever we  
build would not meet the needs of anything if it was done in the  
abstract.