Subject: [sipcore] When to use SIP INFO and SIP INFO-Package

From: Linyi TIAN <[email-masked]>
Date: Tue, 22 Sep 2009 11:54:00 +0800

Hi, All

I have a general question about the guidance when to use SIP INFO and SIP
INFO-Package.

If a MIME can clearly states its application usage, do we still need to use
SIP INFO-Package? Is there any guidance on this?

Compared between the old SIP INFO and new SIP INFO (without info event
framework), is "Info-Package" header the only difference?

Cheers,

Linyi

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 22 Sep 2009 07:06:30 +0200

Hi,

The guidance is: If you are coming up with a new usage of INFO, use
Info-Package - no matter if you could claim that the Content-Type etc
tells it all.

Hopefully the next version of the draft will be more clear on this.

Regards,

Christer

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Tue, 22 Sep 2009 01:20:25 -0400

I believe there were couple of usages which could use legacy INFO:
tunnel ISDN content and provide out of band DTMF. All other should use
the new info package.
 
Sanjay

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Linyi TIAN
	Sent: Tuesday, September 22, 2009 9:24 AM
	To: [email-masked]
	Subject: [sipcore] When to use SIP INFO and SIP INFO-Package

	Hi, All

	I have a general question about the guidance when to use SIP
INFO and SIP INFO-Package.

	If a MIME can clearly states its application usage, do we still
need to use SIP INFO-Package? Is there any guidance on this?

	Compared between the old SIP INFO and new SIP INFO (without info
event framework), is "Info-Package" header the only difference?

	Cheers,

	Linyi

---

From: Linyi TIAN <[email-masked]>
Date: Tue, 22 Sep 2009 14:23:45 +0800

Hi, All

It is not clear to me why we need to use the new INFO method when the
content type can clearly indicate its application usage. What is the benefit
in this case for Info-Package header? I didn't see the difference with
tunnel ISDN usage.

Cheers,

Linyi

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sanjay Sinha (sanjsinh)
Sent: Tuesday, September 22, 2009 1:20 PM
To: Linyi TIAN; [email-masked]
Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package

I believe there were couple of usages which could use legacy INFO: tunnel
ISDN content and provide out of band DTMF. All other should use the new info
package.

Sanjay

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Linyi TIAN
Sent: Tuesday, September 22, 2009 9:24 AM
To: [email-masked]
Subject: [sipcore] When to use SIP INFO and SIP INFO-Package

Hi, All

Cheers,

Linyi

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 22 Sep 2009 08:46:49 +0200

Hi, 

>It is not clear to me why we need to use the new INFO method when the
content type can clearly indicate its application usage. What is the
benefit in this case for Info-Package header? I didn't 
>see the difference with tunnel ISDN usage.

We had long discussions about that, and the outcome and compromise was
the introduction of Info Packages.

But, again, you are not required to change current INFO usages (without
Packages).

Regards,

Christer

On Behalf Of Sanjay Sinha (sanjsinh)

	I believe there were couple of usages which could use legacy
INFO: tunnel ISDN content and provide out of band DTMF. All other should
use the new info package.

	Sanjay

				From: [email-masked]
[mailto:[email-masked]] On Behalf Of Linyi TIAN
		Sent: Tuesday, September 22, 2009 9:24 AM
		To: [email-masked]
		Subject: [sipcore] When to use SIP INFO and SIP
INFO-Package

		Hi, All

		I have a general question about the guidance when to use
SIP INFO and SIP INFO-Package.

		If a MIME can clearly states its application usage, do
we still need to use SIP INFO-Package? Is there any guidance on this?

		Compared between the old SIP INFO and new SIP INFO
(without info event framework), is "Info-Package" header the only
difference?

		Cheers,

		Linyi

---

From: Linyi TIAN <[email-masked]>
Date: Tue, 22 Sep 2009 15:24:39 +0800

Hi, Christer

I was confused. In the scenario I described I don't see the need to use new
SIP INFO method. What is the context for this compromise? As far as I
understand there has to be benefit to reach compromise. It is obviously this
is not the case, right? 

I hope this can be clarified in the new draft as a guidance. Maybe we can
say when MIME is clear enough then old SIP INFO could be enough. When MIME
is not clear enough or negotiation mechanism is needed then the new SIP INFO
and framework is needed. 

Cheers,
Linyi

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Tuesday, September 22, 2009 2:47 PM
To: Linyi TIAN; Sanjay Sinha (sanjsinh); [email-masked]
Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package

Hi, 

Regards,

Christer

	Sanjay

		Hi, All

		Cheers,

		Linyi

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 22 Sep 2009 09:37:31 +0200

Hi, 

>I was confused. In the scenario I described I don't see the 
>need to use new SIP INFO method. What is the context for this 
>compromise? As far as I understand there has to be benefit to 
>reach compromise. It is obviously this is not the case, right? 
>
>I hope this can be clarified in the new draft as a guidance. 
>Maybe we can say when MIME is clear enough then old SIP INFO 
>could be enough. When MIME is not clear enough or negotiation 
>mechanism is needed then the new SIP INFO and framework is needed. 

And how do you know that everyone will have the same understanding of
the MIME as you?

Now, I agree that for ISDN there probably is not an issue. Also, I think
that ISDN tunneling with INFO already exists, so there should be no need
to define an Info Package for that.

But, the draft talks about sending a jpeg as an example. Even if you
support jpegs, sending it without any associated context makes it quite
difficult for the receiver to know what you want him to do with it.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 22 Sep 2009 09:43:30 +0200

In addition, IETF can not prevent you from using INFO in any way you
want :)

The reason we are providing the Info Package mechanism is to try to
solve lots of the interop problems that have occured with the usage of
legacy INFO.

Regards,

Christer

> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 22. syyskuuta 2009 10:38
> need to use 
> >new SIP INFO method. What is the context for this 
> compromise? As far as 
> >I understand there has to be benefit to reach compromise. It is 
> >obviously this is not the case, right?
> >
> could be 
> >enough. When MIME is not clear enough or negotiation mechanism is 
> >needed then the new SIP INFO and framework is needed.
> 
> And how do you know that everyone will have the same 
> understanding of the MIME as you?
> 
> Now, I agree that for ISDN there probably is not an issue. 
> Also, I think that ISDN tunneling with INFO already exists, 
> so there should be no need to define an Info Package for that.
> 
> But, the draft talks about sending a jpeg as an example. Even 
> if you support jpegs, sending it without any associated 
> context makes it quite difficult for the receiver to know 
> what you want him to do with it.
> 
> Regards,
> 
> Christer
> 
> 
> > But, again, you are not required to change current INFO usages 
> > (without Packages).
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 	 
> > 
> [mailto:[email-masked]] On 
> > Behalf Of Sanjay Sinha (sanjsinh)
> > INFO: tunnel ISDN content and provide out of band DTMF. All other 
> > should use the new info package.
> > 
> > 	 
> > 
> > 	Sanjay
> > 
> > 		 
> > 
> > 		I have a general question about the guidance 
> when to use SIP INFO 
> > and SIP INFO-Package.
> > 
> > 		 
> > 
> > 		If a MIME can clearly states its application 
> usage, do we still need 
> > to use SIP INFO-Package? Is there any guidance on this?
> > 
> > 		 
> > 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Linyi TIAN <[email-masked]>
Date: Tue, 22 Sep 2009 16:08:34 +0800

Hi, Christer

I agree with you MIMEs like JPEG is not enough and INFO package is needed.
However I am talking about the case that MIME is clear enough. For example,
if a SDO provides a detailed a specification for a Content Type for a
particular usage then SIP INFO together with this MIME is enough.

In this case I didn't see Info-Package header will help. There are some
discussions in various SDOs about when we need to use this I-D and confusion
comes. I hope IETF can clarify and give guidance on this. 

How about my suggestions as the guidance in last email? 

Cheers,
Linyi

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Tuesday, September 22, 2009 3:38 PM
To: Linyi TIAN; Sanjay Sinha (sanjsinh); [email-masked]
Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package

Hi, 

Regards,

Christer

---

From: Linyi TIAN <[email-masked]>
Date: Tue, 22 Sep 2009 17:03:28 +0800

Hi, Christer

I understand the intention about solving IOP issues. I quite like the
approach we have now in the I-D.

However my concern is that we can't simply tell the industry that we should
use new SIP INFO without any guidance or clear benefit. Not prevent people
to abuse is not a good guidance at all. 

Since there are debate and confusion in various SDOs I believe it is better
to write some guidance about the scenarios I described.

Cheers,
Linyi

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Tuesday, September 22, 2009 3:44 PM
To: Christer Holmberg; Linyi TIAN; Sanjay Sinha (sanjsinh); [email-masked]
Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 22 Sep 2009 11:07:52 +0200

Hi,

The draft tries to explain what the backgrund behind Info Packages is,
and what the advantages of using Info Packages are.

Regards,

Christer

> From: Linyi TIAN [mailto:[email-masked]] 
> Sent: 22. syyskuuta 2009 12:03
> To: Christer Holmberg; 'Sanjay Sinha (sanjsinh)'; [email-masked]
> I understand the intention about solving IOP issues. I quite 
> like the approach we have now in the I-D.
> 
> However my concern is that we can't simply tell the industry 
> that we should use new SIP INFO without any guidance or clear 
> benefit. Not prevent people to abuse is not a good guidance at all. 
> 
> Since there are debate and confusion in various SDOs I 
> believe it is better to write some guidance about the 
> scenarios I described.
> 
> Cheers,
> Linyi
>

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Tue, 22 Sep 2009 05:19:07 -0400

Also you should probably look at the email archives from sip wg around
Sept - Oct 2007. There was detailed discussion about Content-Type and
Info package.

Sanjay

>Sent: Tuesday, September 22, 2009 2:38 PM
>The draft tries to explain what the backgrund behind Info 
>Packages is, and what the advantages of using Info Packages are.
>
>Regards,
>
>Christer
>
>
> 
>
>> However my concern is that we can't simply tell the industry that we 
>> should use new SIP INFO without any guidance or clear benefit. Not 
>> prevent people to abuse is not a good guidance at all.
>> 
>> Since there are debate and confusion in various SDOs I believe it is 
>> better to write some guidance about the scenarios I described.
>> 
>> Cheers,
>> Linyi
>> 
>> > And how do you know that everyone will have the same understanding 
>> > of the MIME as you?
>> > 
>> > Also, I think that ISDN tunneling with INFO already 
>exists, so there 
>> > should be no need to define an Info Package for that.
>> > 
>> > support jpegs, sending it without any associated context makes it 
>> > quite difficult for the receiver to know what you want him to do 
>> > with it.
>> > 
>> > Regards,
>> > 
>> > Christer
>> > 
>> >

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Sep 2009 09:17:09 -0400

If you attempt to use INFO without an info-package, then you also have 
all the other limitations of legacy info use. That usage is quite 
under-specified. You can of course do whatever you want. But your usage 
will essentially be proprietary.

*Where* are you going to specify the meaning of that content-type with 
respect to INFO? How will someone you end up interoperating with 
discover that specification? How will you know if they understood it or not?

The info package mechanism addresses those kinds of issues.

	Thanks,
	Paul

---

From: tianlinyi 34932 <[email-masked]>
Date: Tue, 22 Sep 2009 23:26:50 +0800

Hi, Paul

As i said there is specification clearly states the usage of Content type and a registration with this Content Type will be provided. The specification will also mention how it will be used in SIP INFO, why it is still un-specified?

For example, if 3GPP defines the content type and its usage with SIP INFO in a specification why INFO package hearder should be used? I didn't see any IOP problem on this approach.

Cheers,
Linyi

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
 immediately and delete it!
 *****************************************************************************************

----- 原邮件 -----
发件人: Paul Kyzivat <[email-masked]>
日期: 星期二, 九月 22日, 2009 下午9:17
主题: Re: [sipcore] When to use SIP INFO and SIP INFO-Package
收件人: Linyi TIAN <[email-masked]>
抄送: 'Christer Holmberg' <[email-masked]>, "'Sanjay Sinha (sanjsinh)'" <[email-masked]>, [email-masked]

> >> we still need to use SIP INFO-Package? Is there any guidance on 
> this?>>
> >>                  
> >>

---

From: Dean Willis <[email-masked]>
Date: Tue, 22 Sep 2009 13:23:50 -0500

On Sep 21, 2009, at 10:54 PM, Linyi TIAN wrote:
>
>
> If a MIME can clearly states its application usage, do we still need  

This is somewhat like asking "If carrier pigeons can fly me to the  
IETF meeting, do I need to buy an airplane ticket?"

We've debated at great length, and have not found a case wherein the  
"MIME clearly states its application usage" really works with SIP. I  
suppose one might define new "SIP-only" MIME types that are limited in  
this way, but this clashes with the fundamental philosophy of MIME  
types as describing "what a thing is", rather than "what you should do  
with this thing".

So the answer is: all new usages will need to define SIP INFO packages.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 22 Sep 2009 13:39:55 -0500

On Sep 22, 2009, at 10:26 AM, tianlinyi 34932 wrote:

> Hi, Paul
>
> As i said there is specification clearly states the usage of Content  
> type and a registration with this Content Type will be provided. The  
> specification will also mention how it will be used in SIP INFO, why  
> it is still un-specified?
>
> For example, if 3GPP defines the content type and its usage with SIP  
> INFO in a specification why INFO package hearder should be used? I  
> didn't see any IOP problem on this approach.
>

If 3GPP were to define a new MIME type that is only used in SIP INFO  
messages, then you are correct in that the INFO package framework  
would add little value.

However, this is not how MIME types work.

The MIME type model defines only "what an object is", not "how the  
object can be used". To negotiate around "how the object will be used  
in this application", we need a higher-level of specification and  
negotiation. IN SIP INFO messages, the INFO package definition  
provides that level of specification and negotiation.

The MIME registration process doesn't register things like "This MIME  
type can only be used in a SIP INFO message in accordance with the  
foobar application as documented in 3GPP TS 99.411." And if somebody  
tried to register such a restricted MIME type, I'd hope the ietf-types  
people would say "no."  Of course, there's no guarantee  that no  
broken types are going to be registered (especially in vendor trees),  
but certainly the majority of existing types aren't broken like this.  
Once a type is defined, objects os that type can br transported in  
email, HTTP requests, SIP INFO, NOTIFY, and other requests messages,  
stored in Windows registries, and so on, in countless application  
scenarios that the MIME type registration has no way of predicting or  
controlling. To constrain this diversity in a useful way in the  
context of NOTIFY messages within the SIP protocol, we have  
historically use event packages, and found this approach to work quite  
well. Going forward, in the context of INFO messages within the SIP  
protocol,  we will use INFO packages for the same reasons.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 22 Sep 2009 21:52:51 +0200

Hi,
 
If you can ensure that the INFO will only reach IMS user agents, and that there will be no other usage of the Content Type, then you can do that. In controlled environments it is always easier to make sure everyone has the same "understanding" of things.
 
Please note, though, that 3GPP IMS has adopted the Info Package draft.
 
Regards,
 
Christer

From: tianlinyi 34932 [mailto:[email-masked]]
Sent: Tue 22/09/2009 17:26
To: Paul Kyzivat
Cc: Christer Holmberg; 'Sanjay Sinha (sanjsinh)'; [email-masked]
Subject: Re:Re: [sipcore] When to use SIP INFO and SIP INFO-Package

Hi, Paul

Cheers,
Linyi

----- ??? -----
???: Paul Kyzivat <[email-masked]>
??: ???, ?? 22?, 2009 ??9:17
??: Re: [sipcore] When to use SIP INFO and SIP INFO-Package
???: Linyi TIAN <[email-masked]>
??: 'Christer Holmberg' <[email-masked]>, "'Sanjay Sinha (sanjsinh)'" <[email-masked]>, [email-masked]

---

From: Linyi TIAN <[email-masked]>
Date: Wed, 23 Sep 2009 08:54:11 +0800

Hi, Dean Willis, et al.

I have to say I like your answers which clarify my doubts. May I suggest
adding some words in " 6.  Legacy Uses of INFO" to clarify the new SIP INFO
Package approach and Content Type Approach? Maybe in the introduction
section we can add more information about the Content Type approach. I mean
not only talking about the JPEG example. Even in controlled Content-Type
there maybe issues too as Dean said. 

Current working in introduction section leads me to think about new method
is only applicable for not-controlled Conent-Type.

Quote from Dean's email, rewording maybe
needed---------------------------------------------------------------------
The MIME type model defines only "what an object is", not "how the  
object can be used". To negotiate around "how the object will be used  
in this application", we need a higher-level of specification and  
negotiation. IN SIP INFO messages, the INFO package definition  
provides that level of specification and negotiation.

in countless application scenarios that the MIME type registration has no
way of predicting or  

Cheers,
Linyi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dean Willis
Sent: Wednesday, September 23, 2009 2:40 AM
To: tianlinyi 34932
Cc: 'Sanjay Sinha (sanjsinh)'; [email-masked]
Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package

--
Dean

---

From: Eric Burger <[email-masked]>
Date: Tue, 22 Sep 2009 22:51:41 -0400

How about this:

1. If someone tries to register a MIME type that will "only" be used  
for SIP, there is a near 100% likelihood the registration will not  
pass expert review. Thus you will not have a standard INFO usage. Dean  
explains why: MIME describes multimedia content. MIME does not  
describe multimedia use.

2. If someone tries to document a *new* legacy use of INFO that does  
not use the INFO Framework, there is a near 100% likelihood the  
document will neither pass expert review nor succeed as an individual  
informational submission, as the INFO Framework draft makes clear why  
such documentation may harm the Internet. [Old legacy usages were  
encouraged to be published, but the only usage that I know of that  
anyone will publish the IETF has not published yet is MSML, and that  
is stuck behind two drafts in final, final edits in MEDIACTRL.]

3. IETF will use the INFO Framework for all new INFO usages.  Any  
proprietary use of INFO that does not use the INFO Framework will not  
be an IETF standard.

4. 3GPP (IMS) will use the INFO Framework. Any proprietary use of INFO  
that does not use the INFO Framework will not be an IMS standard.

5. All of your competitors will do their best to advertise how your  
product is totally proprietary and is likely to fail in the field.   
Moreover, your competitors will advertise how your product can harm  
the Internet.  Finally, if someone *does* register your "magic MIME  
type", which is something that is quite possible to happen, *YOUR*  
customers will have to replace / upgrade / remove *YOUR* equipment.  
Most customers in the telecom space will see that and immediately tell  
you to build to the standards. Said differently, your product managers  
will not be very happy with someone who suggests one builds a product  
one cannot sell or even give away.

Given the above, like many people have said, the legacy INFO method  
"works," in that you can build a non-interoperable, non-standard,  
totally proprietary, should not be connected to the Internet product.   
I would also offer such products are a little bit outside the charter  
of the IETF.  We work to build interoperable, standards-based, open,  
Internet products that people can use safely.

Even 3GPP and the ITU-T, for all of the ills many in the IETF would  
accuse them of, would not consider such a proposal.

On Sep 22, 2009, at 8:54 PM, Linyi TIAN wrote:

> needed 
> ---------------------------------------------------------------------

---

From: Dean Willis <[email-masked]>
Date: Tue, 22 Sep 2009 22:53:16 -0500

> there maybe issues too as Dean said.

We've tried to do this in the Introduction to draft-itf-sipcore-info- 
events-00. The text currently says:

> While INFO has been widely adopted for specific application use  
> cases, such as ISUP and DTMF exchange, RFC 2976 [RFC2976] neither  
> defined a negotiation mechanism nor a means by which to explicitly  
> indicate the type of application information contained in the INFO  
> message.  This led to problems associated with static configuration.  
> In addition, the industry realized there was a potential for  
> interoperability problems due to undefined content syntax and  
> semantics.  This draft addresses these deficiencies and provides a  
> framework for explicit negotiation of capabilities and content  
> context using "Info Packages".

> The INFO method as defined by RFC 2976 did not provide any context  
> for the information the request carried.  While it may sometimes be  
> clear what the content is based on the Content-Type, this is only  
> true where there is only one contextual usage of the content-type.  
> For example, if the Content-Type is "image/jpeg", the MIME-attached  
> content is a JPEG image.  However, there are many useful ways a UAS  
> can render an image.  Said differently, there are different contexts  
> for an image in SIP.  The image could be a caller-id picture, a  
> contact icon, a photo for sharing, and so on.  The sender does not  
> know which image to send to the receiver if the receiver supports an  
> image content type.  Likewise, the receiver does not know the  
> context of an image the client is sending if the receiver supports  
> receiving more than one image content type.  Thus, we need a well  
> defined and documented statement of what the information sent is  
> for.  This situation is identical to the context issue in Internet  
> Mail [RFC3458].  RFC 3458 goes into this and other issues in detail.

I would not object to adding material here to further illustrate why  
Content-Type alone is insufficient, assuming we can find a way to say  
it that doesn't further confuse the reader. Of course, I'm not the  
editor of the document, so I can only suggest this as a contributor to  
the working group.

Likewise, you suggested modifying Section 6, Legacy Uses of Info. This  
section starts with:

    Several RFC-defined and other standards-defined uses of RFC 2976  
INFO
    [RFC2976] exist and are in use, as well as numerous proprietary  
uses.
    Appendix B describes some of these usages.  By definition,
    identifying such uses has relied on either static local  
configuration
    or implicit context determination based on the body Content-Type or
    Content-Disposition value or some proprietary mechanism.  This draft
    cannot forbid nor avoid such uses, since local configuration can
    always override standardized mechanisms.

 From what I understand, you are proposing to add some text here that  
essentially explains how Content-Type combined with local  
configuration provided adequate context for the legacy usages of INFO.  
In other words, describing how the constrained environment of RFC 2976  
prevented users from encountering the kinds of problems that INFO- 
package is attempting to prevent. I can see that such text might be  
usefully added here, if we can find a way to say it that doesn't leave  
the average reader even more confused.

--
Dean

---

From: Linyi TIAN <[email-masked]>
Date: Wed, 23 Sep 2009 12:53:19 +0800

Hi, Dean

If you read the following text in introduction section, it may be understood
as when the Content-Type indicates one contextual usage then SIP INFO
Package is not needed. That is what we are debating in other SDOs. 
While it may sometimes be clear what the content is based on the
Content-Type, this is only true where there is only one contextual usage of
the content-type.

This is why I ask questions here and want the author to clarify it in the
I-D. I hope our concerns can be take into account in next revision, e.g.
update the introduction and section 6.

Cheers,
Linyi

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Wednesday, September 23, 2009 11:53 AM
To: Linyi TIAN
Cc: SIPCORE
Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package

--
Dean

---

From: Linyi TIAN <[email-masked]>
Date: Wed, 23 Sep 2009 12:56:18 +0800

You misunderstood my intention. Please see my response to Dean about adding
some text to further explain the benefit for SIP INFO FW and the issue for
SIP INFO.

Cheers,
Linyi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Eric Burger
Sent: Wednesday, September 23, 2009 10:52 AM
To: Linyi Tian
Cc: [email-masked]; SIPCORE; [email-masked]
Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package

How about this:

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 23 Sep 2009 06:57:32 +0200

Hi,

There will be a new version of the draft shortly, where some
re-wording/clarification has been done. Let's see if it is more clear
there.

Regards,

Christer

> Sent: 23. syyskuuta 2009 7:53
> To: 'Dean Willis'
> Cc: 'SIPCORE'
> If you read the following text in introduction section, it 
> may be understood as when the Content-Type indicates one 
> contextual usage then SIP INFO Package is not needed. That is 
> what we are debating in other SDOs. 
> While it may sometimes be clear what the content is based on 
> the Content-Type, this is only true where there is only one 
> contextual usage of the content-type.
> 
> This is why I ask questions here and want the author to 
> clarify it in the I-D. I hope our concerns can be take into 
> account in next revision, e.g.
> > section we can add more information about the Content Type 
> approach.  
> > I mean
> > not only talking about the JPEG example. Even in controlled 
> Content- 
> > Type

---

From: Eric Burger <[email-masked]>
Date: Wed, 23 Sep 2009 06:27:50 -0400

Now I think I understand.  Do we agree the request is to make it very,  
very, very clear that new usages of INFO outside the INFO Framework is  
not only a bad idea but will not be tolerated?  If so, I think we can  
figure out some wording for that.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 23 Sep 2009 13:12:52 +0200

There is text in the draft which says that, for backward compability purpose, legacy usage of INFO is allowed. If needed, we can simply add a statement saying: "Any new usage of INFO MUST use the Info Package mechanism".
 
Regards,
 
Christer

From: [email-masked] on behalf of Eric Burger
Sent: Wed 9/23/2009 12:27 PM
To: Linyi TIAN
Cc: SIPCORE
Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package

---

From: George Foti <[email-masked]>
Date: Wed, 23 Sep 2009 07:43:31 -0400

Yes, I would like a statement that explicitly disallows any usage of INFO outside the framework.
Than we don't have to rehash this discussion once more.

Rgds.

George Foti
Ericsson Canada

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Wednesday, September 23, 2009 7:13 AM
To: Eric Burger; Linyi TIAN
Cc: SIPCORE
Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package

Regards,
 
Christer

Now I think I understand.  Do we agree the request is to make it very, very, very clear that new usages of INFO outside the INFO Framework is not only a bad idea but will not be tolerated?  If so, I think we can figure out some wording for that.

On Sep 23, 2009, at 12:56 AM, Linyi TIAN wrote:

> You misunderstood my intention. Please see my response to Dean about 
> adding some text to further explain the benefit for SIP INFO FW and 
> the issue for SIP INFO.
>
> Cheers,
> Linyi

On Sep 23, 2009, at 12:53 AM, Linyi TIAN wrote:

> Hi, Dean
>
> If you read the following text in introduction section, it may be 
> understood as when the Content-Type indicates one contextual usage 
> then SIP INFO Package is not needed. That is what we are debating in 
> other SDOs.
> Content-Type, this is only true where there is only one contextual 
> usage of the content-type.
>
> This is why I ask questions here and want the author to clarify it in 
> the I-D. I hope our concerns can be take into account in next 
> revision, e.g.
>> I have to say I like your answers which clarify my doubts. May I 
>> suggest adding some words in " 6.  Legacy Uses of INFO" to clarify 
>> the new SIP INFO Package approach and Content Type Approach? Maybe in 
>> the introduction section we can add more information about the 
>> Content Type approach.
>> I mean
>> not only talking about the JPEG example. Even in controlled Content- 
>> Type there maybe issues too as Dean said.
>
>
>
>> image content type.  Likewise, the receiver does not know the context 
>> of an image the client is sending if the receiver supports receiving 
>> more than one image content type.  Thus, we need a well defined and 
>> documented statement of what the information sent is for.  This 
>> situation is identical to the context issue in Internet Mail 
>> [RFC3458].  RFC 3458 goes into this and other issues in detail.
>
>

---

From: George Foti <[email-masked]>
Date: Wed, 23 Sep 2009 08:58:12 -0400

Hi Christer,

Yes, I am referring to including an explicit statement disallowing any NEW info usage outside the Info event framework.
Thanks

George

-----Original Message-----
From: Christer Holmberg 
Sent: Wednesday, September 23, 2009 8:50 AM
To: George Foti; Eric Burger; Linyi TIAN
Cc: SIPCORE
Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package

Hi,

Just to clarify that you are allowed to use existing legacy INFO usages, if such have already been specified.

For example, if you want to support ISUP tunnelling it is perfectly ok to use the current mechanisms. You are not required to define an Info Package for that.

BUT, if you are specifying a *NEW* INFO usage, then you MUST use the Info Package framework.

Regards,

Christer

-----Original Message-----
From: George Foti
Sent: Wed 9/23/2009 1:43 PM
To: Christer Holmberg; Eric Burger; Linyi TIAN
Cc: SIPCORE
Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package

Rgds.

George Foti
Ericsson Canada

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Wednesday, September 23, 2009 7:13 AM
To: Eric Burger; Linyi TIAN
Cc: SIPCORE
Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package

Regards,
 
Christer

---

From: Dean Willis <[email-masked]>
Date: Wed, 23 Sep 2009 08:40:16 -0500

On Sep 23, 2009, at 5:27 AM, Eric Burger wrote:

> Now I think I understand.  Do we agree the request is to make it  
> very, very, very clear that new usages of INFO outside the INFO  
> Framework is not only a bad idea but will not be tolerated?  If so,  
> I think we can figure out some wording for that.

That, and WHY this is so, and also describing how the "legacy" usages  
contact has to be deduced from the content-type and local  
configuration data in more detail.

--
Dean

---

From: tianlinyi 34932 <[email-masked]>
Date: Wed, 23 Sep 2009 22:06:48 +0800

Hi, George

I don't believe this could be mandated in this I-D. If there is no IOP issue for old INFO or potential INFO with clear specification it is free for them to use. Guidance will be enough. 

Cheers,
Linyi

----- 原邮件 -----
发件人: George Foti <[email-masked]>
日期: 星期三, 九月 23日, 2009 下午8:59
主题: Re: [sipcore] When to use SIP INFO and SIP INFO-Package
收件人: Christer Holmberg <[email-masked]>, Eric Burger <[email-masked]>, Linyi TIAN <[email-masked]>
抄送: SIPCORE <[email-masked]>

> Hi Christer,
> 
> Yes, I am referring to including an explicit statement disallowing 
> any NEW info usage outside the Info event framework.
> Thanks
> 
> George
> 
> 
> Just to clarify that you are allowed to use existing legacy INFO 
> usages, if such have already been specified.
> 
> For example, if you want to support ISUP tunnelling it is 
> perfectly ok to use the current mechanisms. You are not required 
> On Behalf Of Christer Holmberg
> There is text in the draft which says that, for backward 
> compability purpose, legacy usage of INFO is allowed. If needed, 
> we can simply add a statement saying: "Any new usage of INFO MUST 
> use the Info Package mechanism".
> 
> Regards,
> 
> Christer
> 
> Framework is not only a bad idea but will not be tolerated?  If 
> so, I think we can figure out some wording for that.
> 
> >> message.  This led to problems associated with static 
> configuration.>> In addition, the industry realized there was a 
> potential for 
> context 
> >    Content-Disposition value or some proprietary mechanism.  
> This 
> > draft
> > configuration provided adequate context for the legacy usages of 
> INFO.> In other words, describing how the constrained environment 
> of RFC 2976

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 23 Sep 2009 14:50:18 +0200

Hi,

Regards,

Christer

-----Original Message-----
From: George Foti
Sent: Wed 9/23/2009 1:43 PM
To: Christer Holmberg; Eric Burger; Linyi TIAN
Cc: SIPCORE
Subject: RE: [sipcore] When to use SIP INFO and SIP INFO-Package

Rgds.

George Foti
Ericsson Canada

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Wednesday, September 23, 2009 7:13 AM
To: Eric Burger; Linyi TIAN
Cc: SIPCORE
Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package

Regards,
 
Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 23 Sep 2009 19:40:49 +0200

Hi,
 
The idea is that the I-P draft replaces the existing RFC. For backward compability it allows existing RFC based solutions, but the idea is that any new usage DOES use the I-P mechanism.
 
Since you will have to describe the semantics etc of the new usage anyway, I really don't see the problem is in doing it in the form of an I-P. Just because, for a specific use-case, you may not need all "features" of the I-P mechanism, I think it is much better to use a single mechanism.
 
Just for my interest: is there some specific new usage you have in mind, where you would like to use legacy INFO?
 
Regards,
 
Christer

From: tianlinyi 34932 [mailto:[email-masked]]
Sent: Wed 23/09/2009 16:06
To: George Foti
Cc: Christer Holmberg; Eric Burger; SIPCORE
Subject: Re:Re: [sipcore] When to use SIP INFO and SIP INFO-Package

Hi, George

Cheers,
Linyi

----- ??? -----
???: George Foti <[email-masked]>
??: ???, ?? 23?, 2009 ??8:59
??: Re: [sipcore] When to use SIP INFO and SIP INFO-Package
???: Christer Holmberg <[email-masked]>, Eric Burger <[email-masked]>, Linyi TIAN <[email-masked]>
??: SIPCORE <[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Sep 2009 18:15:17 -0400

> Just for my interest: is there some specific new usage you have in mind, where you would like to use legacy INFO?

And I saw mention that this was involved with another SDO.
Can you say which one?

	Thanks,
	Paul

---

From: Eric Burger <[email-masked]>
Date: Thu, 24 Sep 2009 07:51:31 -0400

The primary reason we are in the INFO mess in the first place is the  
old, legacy INFO specification allowed people to create usages that  
"worked for them" yet had no way of indicating what the usage is, so  
that it would be impossible to have interoperable UAs that happened to  
use more than one INFO usage.

I strongly disagree with the sentiment that if you happen to not need  
all of the features of the INFO Framework that you might want to use  
the INFO Framework anyway because it is not too hard. Rather, if you  
do not use the INFO Framework, YOU ARE HARMING THE INTERNET BY HARMING  
INTEROPERABILITY.

The interoperability here is not your implementation of your INFO  
usage.  It is the interoperability of your UA with other UAs that have  
other INFO usages.  Life is good if you only talk to yourself or you  
do not use INFO.  In the real world, you presumably talk to other  
devices, many of which will not be under your control.

Use of the INFO Framework, therefore, is mandatory, not just a good  
idea.

That said, unfortunately I have to agree with Linyi - there is no  
protocol way of saying 'you MUST write the correct document.'  That is  
not a protocol thing.  However, IANA and the SIP expert group are now  
aware of this issue, and that[ has the same effect as a ban on new  
INFO usages outside the INFO Framework.

On Sep 23, 2009, at 1:40 PM, Christer Holmberg wrote:

> Hi,
>
> The idea is that the I-P draft replaces the existing RFC. For  
> backward compability it allows existing RFC based solutions, but the  
> idea is that any new usage DOES use the I-P mechanism.
>
> Since you will have to describe the semantics etc of the new usage  
> anyway, I really don't see the problem is in doing it in the form of  
> an I-P. Just because, for a specific use-case, you may not need all  
> "features" of the I-P mechanism, I think it is much better to use a  
> single mechanism.
>
> Just for my interest: is there some specific new usage you have in  
> mind, where you would like to use legacy INFO?
>
> Regards,
>
> Christer
>
> I don't believe this could be mandated in this I-D. If there is no  
> IOP issue for old INFO or potential INFO with clear specification it  
> is free for them to use. Guidance will be enough.
>
> Cheers,
> Linyi
>
> This email and its attachments contain confidential information from  
> HUAWEI, which is intended only for the person or entity whose  
> address is listed above. Any use of the information contained here  
> in any way (including, but not limited to, total or partial  
> disclosure, reproduction, or dissemination) by persons other than  
> the intended recipient(s) is prohibited. If you receive this email  
> in error, please notify the sender by phone or email
> ???: Christer Holmberg <[email-masked]>, Eric Burger  
> <[email-masked]>, Linyi TIAN <[email-masked]>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 24 Sep 2009 13:59:48 +0200

Hi,

I agree with Eric.

There is no protocol way of saying "you MUST write to correct document",
but the I-P draft does provide guidance on what type of information that
an I-P description shall contain. Time will show whether that is enough,
but choosing not to use it in the first place is for sure not going to
make anything better...

Regards,

Christer

> [mailto:[email-masked]] On Behalf Of Eric Burger
> Sent: 24. syyskuuta 2009 14:52
> To: tianlinyi 34932
> Cc: SIPCORE
> The primary reason we are in the INFO mess in the first place 
> is the old, legacy INFO specification allowed people to 
> create usages that "worked for them" yet had no way of 
> indicating what the usage is, so that it would be impossible 
> to have interoperable UAs that happened to use more than one 
> INFO usage.
> 
> I strongly disagree with the sentiment that if you happen to 
> not need all of the features of the INFO Framework that you 
> might want to use the INFO Framework anyway because it is not 
> too hard. Rather, if you do not use the INFO Framework, YOU 
> ARE HARMING THE INTERNET BY HARMING INTEROPERABILITY.
> 
> The interoperability here is not your implementation of your 
> INFO usage.  It is the interoperability of your UA with other 
> UAs that have other INFO usages.  Life is good if you only 
> talk to yourself or you do not use INFO.  In the real world, 
> you presumably talk to other devices, many of which will not 
> be under your control.
> 
> Use of the INFO Framework, therefore, is mandatory, not just 
> a good idea.
> 
> That said, unfortunately I have to agree with Linyi - there 
> is no protocol way of saying 'you MUST write the correct 
> document.'  That is not a protocol thing.  However, IANA and 
> the SIP expert group are now aware of this issue, and that[ 
> has the same effect as a ban on new INFO usages outside the 
> INFO Framework.
> 
> > The idea is that the I-P draft replaces the existing RFC. 
> For backward 
> > compability it allows existing RFC based solutions, but the idea is 
> > that any new usage DOES use the I-P mechanism.
> >
> > I don't believe this could be mandated in this I-D. If 
> there is no IOP 
> > issue for old INFO or potential INFO with clear specification it is 
> > free for them to use. Guidance will be enough.
> >
> > Cheers,
> > Linyi
> >
> > 
> **********************************************************************
> > ******************** This email and its attachments contain 
> > confidential information from HUAWEI, which is intended 
> only for the 
> > person or entity whose address is listed above. Any use of the 
> > information contained here in any way (including, but not 
> limited to, 
> > total or partial disclosure, reproduction, or dissemination) by 
> > persons other than the intended recipient(s) is prohibited. If you 
> > receive this email in error, please notify the sender by phone or 
> > email immediately and delete it!
> > 
> perfectly 
> >> ok to use the current mechanisms. You are not required to 
> define an 
> >> Info Package for that.
> >>
> >> BUT, if you are specifying a *NEW* INFO usage, then you 
> MUST use the 
> >> Info Package framework.
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >> Yes, I would like a statement that explicitly disallows 
> any usage of 
> >> INFO outside the framework.
> >> Behalf Of Christer Holmberg
> compability 
> >> purpose, legacy usage of INFO is allowed. If needed, we can simply 
> >> add a statement saying: "Any new usage of INFO MUST use the Info 
> >> Package mechanism".
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >> Framework is not only a bad idea but will not be 
> tolerated?  If so, I 
> >> think we can figure out some wording for that.
> >>
> >> INFO.> In other words, describing how the constrained 
> environment of 
> >> RFC 2976

---

From: George Foti <[email-masked]>
Date: Thu, 24 Sep 2009 09:57:31 -0400

I hope that IANA does not register things that promotes the legacy usage of INFO.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Thursday, September 24, 2009 8:00 AM
To: Eric Burger; tianlinyi 34932
Cc: SIPCORE
Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package

Hi,

I agree with Eric.

There is no protocol way of saying "you MUST write to correct document", but the I-P draft does provide guidance on what type of information that an I-P description shall contain. Time will show whether that is enough, but choosing not to use it in the first place is for sure not going to make anything better...

Regards,

Christer

> > *******************