Subject: [Sip] INFO and Content Negotiation

From: Eric Burger <[email-masked]>
Date: Fri, 20 Jul 2007 16:13:55 -0400

12 second proof point of why content type doesn't work.

So here comes an INVITE.  I am an INFO-friendly UAS.  I negotiate by using
Accept.

This INVITE has the line:
Accept: application/kpml-response+xml

Wow!  This is great!  I know the UAC *wants* DTMF.  Why?  Because it accepts
a DTMF content type.  Excellent - I can now send them DTMF.

The user enters a digit, and I send an INFO with type
application/kpml-response+xml.

UAC says, "What the heck was that?"

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.

_______________________________________________
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: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sat, 21 Jul 2007 20:51:31 +0200

Hi,

I don't really understand your issue here... Did you send the text using INFO, or something? ;)

Regards,

Christer 

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]] 
> Sent: 20. heinäkuuta 2007 23:14
> To: IETF SIP
> Subject: [Sip] INFO and Content Negotiation
> 
> So here comes an INVITE.  I am an INFO-friendly UAS.  I 
> negotiate by using Accept.
> 
> Wow!  This is great!  I know the UAC *wants* DTMF.  Why?  
> Because it accepts a DTMF content type.  Excellent - I can 
> now send them DTMF.
> 
> 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.
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Eric Burger <[email-masked]>
Date: Sat, 21 Jul 2007 21:41:18 -0400

The point is that content type alone is not sufficient for INFO negotiation.
You are a RFC 4722-aware device.  You advertise you accept a DTMF payload
type.  I am an INFO-aware device.  I see you understand a DTMF payload, so I
send it to you in an *INFO* message.  You barf, because you were expecting
KPML.

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sun, 22 Jul 2007 09:10:18 +0200

Why would I be expecting KPML, if I have only indicated that I support DTMF-over-INFO?

If I was to expect KPML, I would first need to establish a subscription for KPML (or, in our "controlled network", the subscription would be established by default, and I would know you are going to send KPML).

Regards,

Christer

> Sent: 22. heinäkuuta 2007 4:41
> To: Christer Holmberg (JO/LMF); IETF SIP
> Subject: Re: [Sip] INFO and Content Negotiation
> 
> You are a RFC 4722-aware device.  You advertise you accept a 
> DTMF payload type.  I am an INFO-aware device.  I see you 
> understand a DTMF payload, so I send it to you in an *INFO* 
> message.  You barf, because you were expecting KPML.
> 
> 
> now send 
> >> them DTMF.
> >> 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.
> >> 
> >> 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments on the application of sip
> >> 
> > 
> 
> 
>

---

From: Eric Burger <[email-masked]>
Date: Sun, 22 Jul 2007 03:13:49 -0400

That is the point - people have been saying, "I can negotiate INFO by using
Content-Type."  This is a tiny example where using Content-Type to negotiate
"INFO Packages" falls apart.

On 7/22/07 3:10 AM, "Christer Holmberg (JO/LMF)"
<[email-masked]> wrote:

> If I was to expect KPML, I would first need to establish a subscription for
> KPML (or, in our "controlled network", the subscription would be established
> by default, and I would know you are going to send KPML).
> 
> Regards,
> 
> Christer
> 
> 
>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sun, 22 Jul 2007 09:18:35 +0200

Hi,

I still don't get it, but let's take it face-to-face at some point :)

Regards,

Christer 

> Sent: 22. heinäkuuta 2007 10:14
> That is the point - people have been saying, "I can negotiate 
> INFO by using Content-Type."  This is a tiny example where 
> using Content-Type to negotiate "INFO Packages" falls apart.
> 
> 
> > Why would I be expecting KPML, if I have only indicated 
> that I support 
> > DTMF-over-INFO?
> > 
> > If I was to expect KPML, I would first need to establish a 
> > subscription for KPML (or, in our "controlled network", the 
> > subscription would be established by default, and I would 
> know you are going to send KPML).
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> >> You are a RFC 4722-aware device.  You advertise you accept a DTMF 
> >> payload type.  I am an INFO-aware device.  I see you understand a 
> >> DTMF payload, so I send it to you in an *INFO* message.  You barf, 
> >> because you were expecting KPML.
> >> 
> >> 
> >>> I don't really understand your issue here... Did you send 
> the text 
> >>> using INFO, or something? ;)
> >>> 
> >>> Regards,
> >>> 
> >>> Christer
> >>>

---

From: Adam Roach <[email-masked]>
Date: Sun, 22 Jul 2007 09:19:03 -0500

To rephrase what Eric is saying here in base principles: _inferring_ 
what can be done with INFO by examining supported content types is a "Do 
What I Mean" mechanism (as opposed to a "Do What I Say" mechanism). "Do 
What I Mean" is a well-known recipe for interoperability failure. (For a 
well constructed discussion of this, see Jonathan's service indication 
draft).

This is, for example, why we have an "Event" header field in RFC 3265 
instead of simply inferring the event package from MIME type. (In fact, 
this is why I started the draft that became 3265 in the first place -- 
with the dual uses of PINT and presence threatening to take the 
SUBSCRIBE method down the path that INFO unfortunately ended up taking, 
an intervention was necessary).

To re-cast Eric's example from a slightly different angle: imagine that 
a desired usage of INFO most naturally used application/sdp as its 
payload. How would one indicate support for such a usage?

/a

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 23 Jul 2007 02:27:11 +0200

Hi,

I think it is clearly said that INFO is not to be used to directly modify the SIP session, so unless there is an application on top of the SIP session that understands this information it would simply be rejected.

Regards,

Christer

> From: Adam Roach [mailto:[email-masked]] 
> Sent: 22. heinäkuuta 2007 17:19
> To: Christer Holmberg (JO/LMF)
> Cc: Eric Burger; IETF SIP
> To rephrase what Eric is saying here in base principles: 
> _inferring_ what can be done with INFO by examining supported 
> content types is a "Do What I Mean" mechanism (as opposed to 
> a "Do What I Say" mechanism). "Do What I Mean" is a 
> well-known recipe for interoperability failure. (For a well 
> constructed discussion of this, see Jonathan's service 
> indication draft).
> 
> This is, for example, why we have an "Event" header field in 
> RFC 3265 instead of simply inferring the event package from 
> MIME type. (In fact, this is why I started the draft that 
> became 3265 in the first place -- with the dual uses of PINT 
> and presence threatening to take the SUBSCRIBE method down 
> the path that INFO unfortunately ended up taking, an 
> intervention was necessary).
> 
> To re-cast Eric's example from a slightly different angle: 
> imagine that a desired usage of INFO most naturally used 
> application/sdp as its payload. How would one indicate 
> support for such a usage?
> 
> /a
> 
> >> That is the point - people have been saying, "I can 
> negotiate INFO by 
> >> using Content-Type."  This is a tiny example where using 
> Content-Type 
> >> to negotiate "INFO Packages" falls apart.
> >>
> >>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 23 Jul 2007 02:37:18 +0200

Hi,

I forgot the part about the indication of the support.

I agree that Accept: application/sdp itself may not be enough to indicate the support for the specific usage.

So, either you could have e.g. an option-tag, some application identifier, an extention to the Accept header - or we would simply say that INFO cannot be used to transport SDP (as I've said many times, I am not proposing to allow to use INFO for whatever people want to).

Regards,

Christer 

> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: 23. heinäkuuta 2007 3:27
> To: Adam Roach
> Cc: IETF SIP
> Subject: RE: [Sip] INFO and Content Negotiation
> 
> 
> Hi,
> 
> I think it is clearly said that INFO is not to be used to 
> directly modify the SIP session, so unless there is an 
> application on top of the SIP session that understands this 
> information it would simply be rejected.
> 
> Regards,
> 
> Christer
> 
> 
>  
> 
> > _inferring_ what can be done with INFO by examining 
> supported content 
> > types is a "Do What I Mean" mechanism (as opposed to a "Do 
> What I Say" 
> > mechanism). "Do What I Mean" is a well-known recipe for 
> > interoperability failure. (For a well constructed 
> discussion of this, 
> > see Jonathan's service indication draft).
> > 
> > instead of simply inferring the event package from MIME type. (In 
> > fact, this is why I started the draft that became 3265 in the first 
> > place -- with the dual uses of PINT and presence 
> threatening to take 
> > the SUBSCRIBE method down the path that INFO unfortunately ended up 
> > taking, an intervention was necessary).
> > 
> > application/sdp as its payload. How would one indicate support for 
> > such a usage?
> > 
> > /a
> >

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 23 Jul 2007 02:40:25 +0200

...and I guess you would also use another content-disposition value than "session" in your usage (again, since INFO cannot be used to directly modify the SIP session).

NOW I'm done with the reply to your e-mail ;)

Regards,

Christer

> Sent: 23. heinäkuuta 2007 3:37
> To: Adam Roach
> Cc: IETF SIP
> I agree that Accept: application/sdp itself may not be enough 
> to indicate the support for the specific usage.
> 
> So, either you could have e.g. an option-tag, some 
> application identifier, an extention to the Accept header - 
> or we would simply say that INFO cannot be used to transport 
> SDP (as I've said many times, I am not proposing to allow to 
> use INFO for whatever people want to).
> 
> Regards,
> 
> Christer 
> 
> 
> > I think it is clearly said that INFO is not to be used to directly 
> > modify the SIP session, so unless there is an application on top of 
> > the SIP session that understands this information it would 
> simply be 
> > rejected.
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> >  
> > 
> support for

---

From: "Xavier Marjou" <[email-masked]>
Date: Mon, 23 Jul 2007 23:45:13 -0500

Hi Eric,

I also do not understand why it would not be possible to indicate in
the transaction of the initial INVITE what type of INFO is exactly
required/supported (negotiation and subscription stage) and to send
the event information with an INFO during the dialog (notification
stage).

Concerning draft-burger-sip-info-00, I think the draft is not fair
with this poor INFO message.  Indeed, the INFO message helps a lot to
quickly implement/have some features (e.g. full intra requests of
mmusic-xml-media-control, DTMF, MSCML, ...) while waiting for
implementations of the IETF standardized solutions (e.g.
rtcp-feedback, kpml, media-control, ...). Though I agree there are
some cons with features based on INFOs messages, there are also some
pros with this approach, (ie: same as for everything ;-) but I won't
go over such details. Thus, I think that even if the IETF does not
want to recommend the INFO message, the IETF should at least recognize
it for experimental uses (i.e. roughly an equivalent of RTCP APP
packet) and even documents these uses. Otherwise, we can end up with
some types of INFO messages that are broadly used but that are even
not documented within IETF documents (e.g. application/dtmf-relay for
INFO with DTMF)

Xavier

---

From: Eric Burger <[email-masked]>
Date: Tue, 24 Jul 2007 07:16:28 -0500

Indicating the package is possible; it is what Dean's draft of 4 years ago
proposed.  However, it is not what is there today.  Moreover, it is doubtful
that any of the myriad INFO exploits would use the mechanism.  If one is
going to upgrade one's mechanism, one might as well do the right thing.

I would also offer we learn the lesson from the e-mail world of X-mumble
headers.

It is true that we need a mechanism to experiment with new extensions to
SIP.  However, formalizing that mechanism is asking for a rash of
incompatible half-baked protocols, some of which, while broken, hijack SIP.

The INFO draft as it currently stands still "allows" for such
experimentation with INFO.  It sounds like if we do want to work on this
draft, the language needs to be clearer that (1) INFO is not gone and (2)
INFO is *not* how you deploy something outside of the lab.

Just for those who may have missed it, Section 4 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 clause.

On 7/23/07 11:45 PM, "Xavier Marjou" <[email-masked]>
wrote:

>> 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: [email-masked]
Date: Tue, 24 Jul 2007 12:05:07 -0400

These issues seem to be all related.  E-mail Mime can make do with
Content-Type because e-mail's sole function is to present information
to the user.  The only information needed is "What is this?" because
"What should I do with this?" is constant.

In SIP, we have the Content-Disposition, with the defined values
"session", "render", "alert", and "icon".  This answers the question
"What should I do with this?", which is independent of "What is
this?".

We've been quite sloppy about this issue because for most methods
"What should I do with this?" is strongly implied by the method or the
context or the Content-Type.

But with INFO, unless there is a tightly constrained context from some
non-SIP feature, there is complete decoupling between "What is this?"
and "What should I do with this?".  That is, any body part needs a
Content-Disposition that identifies what should be done with the
information (= what application the information should be delivered
to).

But we have no method for negotiating what Content-Dispositions are
supported by a given SIP UA.  So of course it doesn't work well.

Dale

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 24 Jul 2007 13:33:14 -0400

Inline...

> Sent: Tuesday, July 24, 2007 8:16 AM
> To: Xavier Marjou
> Cc: IETF SIP

I'm actually not convinced of that.  I don't think people only use INFO
because it was convenient for experimentation, and that given the choice of
modifying it to fix some issues vs. completely changing how they implement
feature XYZ, that they would choose the latter.  I think they use INFO
because it achieves what they need to do in the simplest and most scalable
way, and the KISS principle is strong motivation for many.  

In particular, for the DTMF use of INFO my guess is many vendors would be
willing to add explicit negotiation, rather than doing subscribe-KPML. (so
long as the negotiation itself was simple)

-hadriel

---

From: [email-masked]
Date: Tue, 24 Jul 2007 17:15:20 -0400

From: [email-masked]

   Dale

---

From: [email-masked]
Date: Tue, 24 Jul 2007 17:18:09 -0400

I sent that last message too quickly:

But as someone suggested at the microphone, if people coin new methods
(starting with "X-"), those methods *can* encode "What should I do
with this?"  And the Allow header allows UAs to negotiate what methods
are supported.

I see no problem with proliferating methods, as that is no worse than
proliferating Content-Dispositions.

Dale

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 24 Jul 2007 23:25:47 +0200

> proliferating Content-Dispositions.

Well, for one it could cause existing proxies to Record-Route such requests 
as they would not know the method and would therefore be forced to assume it 
to be dialog creating. So there is some overhead, compared to C-D as 
extension point

Also, in practice I would expect unknown content-dispositions to interwork 
better than unknown methods, especially through proxies

Regards,
Jeroen

---

From: [email-masked]
Date: Tue, 24 Jul 2007 23:52:39 -0400

From: "Jeroen van Bemmel" <[email-masked]>

   > proliferating Content-Dispositions.

   Well, for one it could cause existing proxies to Record-Route such
   requests as they would not know the method and would therefore be
   forced to assume it to be dialog creating. So there is some
   overhead, compared to C-D as extension point

IIRC, there's a set of rules that avoid Record-Routing except in the
first request or two of a dialog.  Scott Lawrence once explained them
to me, and I checked them, and they're method-independent (as one
would expect).

Proxies shouldn't care about the method.  SBCs might be more trouble,
but I expect quality SBCs to be method-agnostic too.

Dale