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

Eric Burger eburger at standardstrack.com
Wed Sep 23 04:51:41 CEST 2009


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:

> 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
> 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.
>
> Cheers,
> Linyi
>
> -----Original Message-----
> From: sipcore-bounces at ietf.org [mailto:sipcore-bounces at ietf.org] On  
> Behalf
> Of Dean Willis
> Sent: Wednesday, September 23, 2009 2:40 AM
> To: tianlinyi 34932
> Cc: 'Sanjay Sinha (sanjsinh)'; sipcore at ietf.org
> Subject: Re: [sipcore] When to use SIP INFO and SIP INFO-Package
>
>
> 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
>
> _______________________________________________
> sipcore mailing list
> sipcore at ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> sipcore mailing list
> sipcore at ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore



More information about the Ietf-types mailing list