Subject: [Sip] RE: I-D ACTION:draft-burger-sip-info-00.txt

From: "Elwell, John" <[email-masked]>
Date: Wed, 04 Jul 2007 14:31:46 +0100

Eric,

I would just like to correct a slight inaccuracy in this draft. RFC 3372
does not specify the use of INFO for QSIG, but RFC 3204 (which is
referenced by RFC 3372) does define the MIME type for QSIG. The
transport of QSIG using the SIP INFO method is instead specified in
Standard ECMA-355 from Ecma-International. This is indeed a very similar
usage of INFO to that specified in RFC 3372 and should be allowed in the
proposed update to RFC 2976.

John 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 03 July 2007 19:15
> To: [email-masked]
> Subject: I-D ACTION:draft-burger-sip-info-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: Session Initiation Protocol (SIP) 
> INFO Method Context
> 	Author(s)	: E. Burger
> 	Filename	: draft-burger-sip-info-00.txt
> 	Pages		: 8
> 	Date		: 2007-7-3
> 	
>    The purpose of the INFO request for the Session Initiation Protocol
>    (SIP), as described by RFC 2976, is to provide mid-session SIP User
>    Agent (UA)-to-SIP UA application data transport.  In the 
> years since
>    the introduction of the INFO request, experience with the 
> use of the
>    INFO request indicates a number of problems.  This 
> document explains
>    why there   flaws of using INFO; and explains why it is 
> not possible to create a
>    framework to rescue INFO for general purpose use.  Thus, this
>    document restricts the use of INFO to that described in RFC 3372
>    (SIP-T).
>  are INFO-based, proprietary protocols in the wild; the
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-burger-sip-info-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in 
> the body of 
> the message. 
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-burger-sip-info-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-burger-sip-info-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

_______________________________________________
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: Peili Xu <[email-masked]>
Date: Thu, 05 Jul 2007 11:20:19 +0800

Hi Eric et al,

I would appreciate this draft for detailed analysis for
the flaws of using INFO.

But since we are touching some proprietary
implementations now, 
I don't think we can ever prohibit implementation of
such usage even a new RFC is published.

I guess people started to use INFO just because it was
the only seemingly suitable mid-dialg
SIP Request at that time. In fact, for proprietary
implementation, people can still use other requests
(introduced later e.g. MESSAGE) for the same purpose. Do
we need to explicit prohibiting using of MESSAGE for
such purpose, if similar implementations evolve in the
future?

People are using INFO to fulfill some real requirements,
if we belive INFO is not the right way, 
I would propose we start to find and standardize more
prefered solution instead of just prohibiting using of
sth.
We've already done sth for DTMF, right?

Instead of updating RFC 2976 just for this purpose,
maybe an informational document to give some guidline is
enough.

Regards.
Peili

>    Agent (UA)-to-SIP UA application data transport.
In the years 
> since
>    the introduction of the INFO request, experience
with the use of 
> the
document 
> explains
http://www.ietf.org/internet-drafts/draft-burger-sip-inf
o-00.txt
> [email-masked] with the word
unsubscribe in the body of 
> logging in, type "cd internet-drafts" and then "get 
> draft-burger-sip-info-00.txt".
> 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 	"FILE
/internet-drafts/draft-burger-sip-info-00.txt".
> 	a MIME-compliant mail reader.  Different
MIME-compliant mail readers

_______________________________________________
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: Eric Burger <[email-masked]>
Date: Thu, 05 Jul 2007 16:49:48 -0400

Good catch.  I'll fix that if there is another draft.

>> implementation to automatically retrieve the ASCII version of the

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

---

From: Eric Burger <[email-masked]>
Date: Thu, 05 Jul 2007 16:56:12 -0400

I was trying to be subtle for those that knew, and not so subtle for those
that do not folks.

Believe me, the folks at my old (and, for that matter, new) employer would
probably get upset if I said, "MSCML is not allowed to work."  Likewise, I
think folks at my old nemesis and my new found best friends would get upset
if I said, "MSML is not allowed to work."

However, I did NOT want to be seen as leaving the door open for more and
more uses of INFO.  What the draft sets out to do is say, "The one and only
IETF sanctioned use of INFO is for the SIP-T case."  I.e., there won't be
any Standards Track INFO RFC's.  However, to keep everyone with a legacy
happy, Section 4 subtly states:

   In recognition of existing, proprietary use of INFO, proxies MUST NOT
   take any action other than that described by RFC 3261 and RFC 2976
   with respect to handling INFO requests.

This is the escape hatch: one can still use INFO, subject to all of the
dangers enumerated in Section 2.  Moreover, the draft explicitly states that
SIP "network elements" must not "add value" by killing INFO messages they do
not understand.