Subject: RE: [Sip] Additional uses of INFO

From: "Nataraju Basavaraju" <[email-masked]>
Date: Wed, 14 Jun 2006 03:12:52 -0700

Hi Keith/Jonathan, 

This new draft lists out the brief details about the CURRENT standards/drafts related to SIP. 

Even now itself so many bugs raised against many RFCs but they have not been fixed in the standard documents. 

If we dont update the RFCs in ietf repository, We might end up in writing one more draft to list out additional drafts/RFCs added once this particular draft becomes an RFC. 

Hence I feel shall we need to define an interval by which this and other existing RFCs/drafts would fix the open bugs related respective RFCs. 

In this way we can help to avoid counfusion for the new entrant to SIP world... 

Regards,
Nataraju A.B.

-----Original Message-----
From: Drage, Keith (Keith) [mailto:[email-masked]]
Sent: Wed 6/14/2006 2:36 AM
To: [email-masked]
Subject: [Sip] Additional uses of INFO
 
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-hitchhikers-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

The information contained in this message may be confidential to Kodiak Networks, Inc. and its subsidiaries and protected from disclosure. If this message did not reach the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby informed that any distribution or copying of this communication is prohibited. If you have received this communication in error, please notify us immediately by replying to the sender of the message and then delete the message. Thank you.
_______________________________________________
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: "Jesske, R" <[email-masked]>
Date: Wed, 21 Jun 2006 08:20:18 +0200

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

There are thoughts to use INFO for MCID (Malicious Communication Identification) to fulfil a TISPAN requirement described in draft-jesske-sipping-tispan-requirements-02. MCID is a regulatory service. One requirement is:

REQ-MCID-2: 
For interoperability reasons, the MCID simulation service logic needs to get the knowledge that, even if the originator identity is missing in the signalling, it can available upon request. This is due to, e.g., interworking with the PSTN network, where, in some cases, the originator's identity is only available upon explicit request. The information can be received asynchronously in a time-frame of 1-30 seconds even after the session has been closed.

So we need the binding to the dialog to have a proper interworking with the PSTN/ISDN to retrieve the information.

So after this discussion it looks for me that INFO is a good candidate and can be used but we need some further description to rule the content of INFO out as Dean pointed out.

Am I correct.

Thanks

Best Regards

Roland

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 21 Jun 2006 10:27:54 +0100

And now, for a view from the other side of the peanut gallery:

I think INFO is potentially a great mechanism for exchanging  
structured data  within dialog-bounded applications (perhaps not  
extensions 

[Chris Boulton] Dean - You should really take a look at the new Control
Framework
(http://www.ietf.org/internet-drafts/draft-boulton-sip-control-framework
-02.txt) that is currently being worked on by a bunch of folks for the
primary purpose of media server control.  It has the agnostic structure
and explicit extension mechanism for exchanging 'structured data' in a
reliable manner.  It might require a new, more suitable primitive, but
that bit is easy.

Chris.

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you.