Subject: [Ecrit] draft-ecall: sending of Info Packages in INFO responses

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Apr 2016 07:40:01 +0000

Hi,

Section 9.2 of draft-ecall allows bodies associated with Info Packages in INFO responses. The text does recognize it is now allowed per RFC 6086, but gives some kind of "exception" for ecall usage.

As far as I know (please correct me if I'm wrong), we have never agreed on such exception, and there has never been any consulting with SIPCORE (there may be a good reason why it's not allowed). I am not even sure draft-ecall can make such exception without updating RFC 6086.

My apologies for this late comment, but I *think* I have commented on this earlier.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Apr 2016 08:13:09 +0000

Correction: NOT allowed per RFC 6086.

Regards,

Christer

From: Ecrit [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 13 April 2016 10:40
To: [email-masked]
Subject: [Ecrit] draft-ecall: sending of Info Packages in INFO responses

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Apr 2016 11:59:52 +0000

Hi,

Ok, it seems like I should have read the paragraph to the end. The suggestion is to not send the data as an Info-Package in the INFO response, but as a generic body.

While not "illegal", I think that is bad protocol design, and not how INFO was supposed to be used. The reason we allowed non-Info-Packages bodies in INFO responses was for backward compatibility - if there is a node that does not support RFC 6080 and inserts some body in a INFO response.

Regards,

Christer

From: Ecrit [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 13 April 2016 11:13
To: [email-masked]
Subject: Re: [Ecrit] draft-ecall: sending of Info Packages in INFO responses

Regards,

Christer

From: Ecrit [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 13 April 2016 10:40
To: [email-masked]<mailto:[email-masked]>
Subject: [Ecrit] draft-ecall: sending of Info Packages in INFO responses

Hi,

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Thu, 14 Apr 2016 00:40:38 -0700

Hi Christer,

I don't see why you think it's bad protocol design.  Keep in mind 
that, unlike with INFO packages in general, the draft is limited to 
emergency calls between a vehicle and a PSAP, where both ends expect 
certain specific body parts (i.e., an MSG and a control block). 
There's no harm in using an INFO request to send a control block, and 
an INFO response to send the MSD in reply.  The alternative would be 
to make INFO an exception to the additional-data mechanism, with INFO 
being the only message where emergency call data can't be sent in its 
response.  This would force a reply to be sent in a new INFO request, 
which makes things more verbose (something you specifically have been 
urging us to avoid doing) for no benefit.

--Randy

At 11:59 AM +0000 4/13/16, Christer Holmberg wrote:

>  Content-Language: en-US
>  Content-Type: multipart/alternative;
>   boundary="_000_7594FB04B1934943A5C02806D1A2204B37F34525ESESSMB209erics_"
>
>  Hi,
>
>  Ok, it seems like I should have read the paragraph to the end. The 
> suggestion is to not send the data as an Info-Package in the INFO 
> response, but as a generic body.
>
>  While not "illegal", I think that is bad protocol design, and not 
> how INFO was supposed to be used. The reason we allowed 
> non-Info-Packages bodies in INFO responses was for backward 
> compatibility - if there is a node that does not support RFC 6080 
> and inserts some body in a INFO response.
>
>  Regards,
>
>  Christer
>
>  From: Ecrit 
> [<mailto:[email-masked]>mailto:[email-masked]] On 
> Behalf Of Christer Holmberg
>  To: <mailto:[email-masked]>[email-masked]
>  Section 9.2 of draft-ecall allows bodies associated with Info 
> Packages in INFO responses. The text does recognize it is now 
> allowed per RFC 6086, but gives some kind of "exception" for ecall 
> usage.
>
>  As far as I know (please correct me if I'm wrong), we have never 
> agreed on such exception, and there has never been any consulting 
> with SIPCORE (there may be a good reason why it's not allowed). I 
> am not even sure draft-ecall can make such exception without 
> updating RFC 6086.
>
>  _______________________________________________
>  Ecrit mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/ecrit

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
There are three possible parts to a date, of which at least two
must be offered: entertainment, food, and affection.  It is
customary to begin a series of dates with a great deal of
entertainment, a moderate amount of food, and the merest
suggestion of affection.  As the amount of affection increases,
the entertainment can be reduced proportionately.  When the
affection IS the entertainment, we no longer call it dating.
Under no circumstances can the food be omitted.
      --Miss Manners' Guide to Excruciatingly Correct Behavior

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Apr 2016 08:00:22 +0000

Hi,

>I don't see why you think it's bad protocol design.

It is, because:

1) You want to use different mechanisms for sending the body depending on
whether it¹s sent in a request or response.

2) When we did RFC 6086, we explicitly decided that INFO bodies shall be
sent in requests only. The ONLY reason for allowing non-Info-Packages
bodies in a response was for backward compatibility with RFC 2976
endpoints.

>Keep in mind that, unlike with INFO packages in general, the draft is
>limited to
>an INFO response to send the MSD in reply.

We can not allow specific INFO usages to decide that the rules don¹t have
to be followed, just because they think it¹s ok for their specific case -
without even consulting SIPCORE.

>The alternative would be

I am sure I indicated that earlier, when the mechanism was discussed: you
can only send information in INFO requests.

Also, the statement in the additional-data draft, saying that data can be
sent in "any SIP request and response", can NOT override rules associated
with specific requests and responses. It would probably be good to clarify
that in the additional-data draft.

Regards,

Christer

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 14 Apr 2016 09:22:30 +0000

It is bad protocol design for exactly the same reason that INFO is defined the way it is.

With SIP, UDP is allowed, and responses form part of the protocol mechanism that confirms a piece of data has been received. Therefore one should not put information in SIP responses unless:

1)	One is prepared to lose it because it did not matter anyway.
2)	Its usage is tied to receiving the response, therefore if the response itself is not received, the information does not matter.

I do not think we should be treating data relating to the emergency call under these considerations.

In the INFO mechanism, the response to INFO indicates that that INFO request and its contents, had been received and delivered to the application using the INFO mechanism. You have no way of doing the equivalent by putting the data in a normal SIP response.

Now of course, one could deprecate UDP, but if you want to go that way, we need an RFC 3261 bis.

Regards

Keith

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of EXT Christer Holmberg
Sent: 14 April 2016 09:00
To: Randall Gellens; [email-masked]
Subject: Re: [Ecrit] draft-ecall: sending of Info Packages in INFO responses

Hi,

It is, because:

1) You want to use different mechanisms for sending the body depending on whether it¹s sent in a request or response.

2) When we did RFC 6086, we explicitly decided that INFO bodies shall be sent in requests only. The ONLY reason for allowing non-Info-Packages bodies in a response was for backward compatibility with RFC 2976 endpoints.

>limited to emergency calls between a vehicle and a PSAP, where both 
>ends expect certain specific body parts (i.e., an MSG and a control 
>block).

We can not allow specific INFO usages to decide that the rules don¹t have to be followed, just because they think it¹s ok for their specific case - without even consulting SIPCORE.

>urging us to avoid doing) for no benefit.

I am sure I indicated that earlier, when the mechanism was discussed: you can only send information in INFO requests.

Also, the statement in the additional-data draft, saying that data can be sent in "any SIP request and response", can NOT override rules associated with specific requests and responses. It would probably be good to clarify that in the additional-data draft.

Regards,

Christer

>> compatibility - if there is a node that does not support RFC 6080 and 
>> inserts some body in a INFO response.
>>
>>  Regards,
>>
>>  Christer
>>
>> Packages in INFO responses. The text does recognize it is now allowed 
>> per RFC 6086, but gives some kind of "exception" for ecall usage.
>>
>> with SIPCORE (there may be a good reason why it's not allowed). I am 
>> not even sure draft-ecall can make such exception without updating 
>> RFC 6086.
>>
>-------------- Randomly selected tag: --------------- There are three 
>possible parts to a date, of which at least two must be offered: 
>entertainment, food, and affection.  It is customary to begin a series 
>of dates with a great deal of entertainment, a moderate amount of food, 
>and the merest suggestion of affection.  As the amount of affection 
>increases, the entertainment can be reduced proportionately.  When the

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Apr 2016 13:41:26 -0400

Hi,

Christer asked me to comment on this. I haven't been following closely, 
so I just now reviewed the draft.

I am less concerned than Christer about the use of responses to INFO to 
carry ecall message bodies. The usage isn't specifically related to 
INFO, it is just following the standard mechanism from the 
additional-data draft for attaching data to arbitrary requests and 
responses. So I find attaching to an INFO response to be no worse than 
attaching to an INVITE response.

But I share some of Keith's concern about bad protocol design. There has 
been an attempt to deal with Keith's concern about loss of data in 
responses, by the introduction of <ack>. But I think it still has some 
problems:

- Things that result in other messaging in the other direction are not 
acked. But if such a request is sent and a message of the requested type 
is then received, there is some ambiguity whether the message was the 
expected response or an unsolicited message. This could result in confusion.

- There is no specification of what to do if a message is sent and the 
expected response is not received. How long should you wait before 
concluding the message was lost? And what should then be done?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Apr 2016 20:49:54 +0000

Hi,

...

>I am less concerned than Christer about the use of responses to INFO to carry ecall message bodies. The usage isn't specifically related to INFO, it is just following the standard mechanism from the >additional-data draft for attaching data to arbitrary requests and responses. So I find attaching to an INFO response to be no worse than attaching to an INVITE response.

If we think it's ok to carry bodies in INFO responses, then it should be brought to SIPCORE, and RFC 6086 should be updated. RFC 6086 currently says MUST NOT (the additional-data draft cannot override that rule).

Or, do we want to take a path where people are allowed to not care about the MUSTs, MUST NOTs etc whenever they think it won't matter???

Regards,

Christer

On 4/14/16 5:22 AM, Drage, Keith (Nokia - GB) wrote:
>>> allowed per RFC 6086, but gives some kind of "exception" for ecall usage.
>>>
>> entertainment, food, and affection.  It is customary to begin a 
>> series of dates with a great deal of entertainment, a moderate amount 
>> of food, and the merest suggestion of affection.  As the amount of 
>> affection increases, the entertainment can be reduced 
>> proportionately.  When the affection IS the entertainment, we no longer call it dating.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Apr 2016 17:40:40 -0400

> Or, do we want to take a path where people are allowed to not care about the MUSTs, MUST NOTs etc whenever they think it won't matter???

While I'm not fond of the approach taken, I don't think it violates 
rfc6086. When a body is added to an INFO response, that body is not 
"associated with the INFO message". It is associated with a Call-Info 
header field, as defined in the additional-info draft.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Apr 2016 21:54:01 +0000

Hi,

>>> I am less concerned than Christer about the use of responses to INFO to carry ecall message bodies. The usage isn't specifically related to INFO, it is just following the standard mechanism from the >>>additional-data draft for attaching data to arbitrary requests and responses. So I find attaching to an INFO response to be no worse than attaching to an INVITE response.
>>
>While I'm not fond of the approach taken, I don't think it violates rfc6086. When a body is added to an INFO response, that body is not "associated with the INFO message". It is associated with a Call->Info header field, as defined in the additional-info draft.

So, why did we invent the Info-Package concept to begin with? The RFC even says that new INFO usages must use Info-Packages. What makes it ok to not use them in responses?

A I said before, the only reason we allow bodies in INFO responses is for backward compatibility (previously it was allowed, or at least not forbidden, to include bodies in INFO responses).

Regards,

Christer

>>> Keep in mind that, unlike with INFO packages in general, the draft 
>>> is limited to emergency calls between a vehicle and a PSAP, where 
>>> both ends expect certain specific body parts (i.e., an MSG and a 
>>> control block).
>>> There's no harm in using an INFO request to send a control block, 
>>> and an INFO response to send the MSD in reply.
>>
>>> to make INFO an exception to the additional-data mechanism, with 
>>> INFO being the only message where emergency call data can't be sent 
>>> in its response.  This would force a reply to be sent in a new INFO 
>>> request, which makes things more verbose (something you specifically 
>>> have been urging us to avoid doing) for no benefit.
>>
>>>>    Ok, it seems like I should have read the paragraph to the end. 
>>>> The suggestion is to not send the data as an Info-Package in the 
>>>> INFO response, but as a generic body.
>>>>
>>>>    While not "illegal", I think that is bad protocol design, and 
>>>> not how INFO was supposed to be used. The reason we allowed 
>>> -------------- Randomly selected tag: --------------- There are 
>>> three possible parts to a date, of which at least two must be offered:
>>> series of dates with a great deal of entertainment, a moderate 
>>> amount of food, and the merest suggestion of affection.  As the 
>>> amount of affection increases, the entertainment can be reduced

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Apr 2016 18:31:16 -0400

> A I said before, the only reason we allow bodies in INFO responses is for backward compatibility (previously it was allowed, or at least not forbidden, to include bodies in INFO responses).

I still don't see this as having anything to do with *INFO*.

This is really about body parts that are present because they are 
referenced by a header field. It isn't much different by-value PIDF-LO 
bodies referenced from geoloc headers, or STIR signatures. (AFAIK 
neither of those currently go in INFO requests or responses, but in 
principle they could.)

In the use here, the body has nothing to do with the kind of message. It 
could in principle go in any sip request or response that happens to be 
going in the desired direction at the time.

They did make a special case when they send their body in INFO 
*requests*, in that they actually define and use an INFO package for the 
purpose. So they use a different Content-Disposition when sending in 
INFO requests than they do everywhere else.

Don't get me wrong - I don't like the way this is all designed, it is an 
ugly hack, and a terrible example of tunneling another protocol over 
sip. (Using INFO packages alone, in both directions, is the recommended 
way of tunneling another protocol over SIP.) But I don't think they are 
technically violating rfc6086.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Fri, 15 Apr 2016 17:26:37 -0700

At 1:41 PM -0400 4/15/16, Paul Kyzivat wrote:

>  - Things that result in other messaging in the other direction are 
> not acked. But if such a request is sent and a message of the 
> requested type is then received, there is some ambiguity whether 
> the message was the expected response or an unsolicited message. 
> This could result in confusion.

An eCall control block acknowledgment carries the CID of the data 
block being acknowledged.

-------------- Randomly selected tag: ---------------
I employ no person who smokes.      --- Thomas Edison
[Handwritten note by Edison to Henry Ford, April 26, 1914

---

From: Randall Gellens <[email-masked]>
Date: Fri, 15 Apr 2016 17:49:03 -0700

At 6:31 PM -0400 4/15/16, Paul Kyzivat wrote:

>  a terrible example of tunneling another protocol over sip. (Using 
> INFO packages alone, in both directions, is the recommended way of 
> tunneling another protocol over SIP.)

Hi Paul,

Thanks for your thoughts, I appreciate it.  On this specific issue, I 
see it differently: the scope of the draft is emergency calls, and 
the data being conveyed part of the emergency call.  In the typical 
case, the eCall MSD is carried in the INVITE request that sets starts 
the emergency call, and the acknowledgment is carried in the INVITE 
response.  To me, this isn't tunneling, this is an enhancement.  I 
think of tunneling as using one protocol only to carry another.  If 
we had a protocol that was unrelated to establishing SIP sessions and 
we carried that protocol in a SIP INVITE, then I'd agree that would 
be tunneling.

-------------- Randomly selected tag: ---------------
Nothing is as irritating as a man who chats pleasantly while he's
overcharging you.                                   --Kin Hubbard

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 16 Apr 2016 11:10:58 +0000

Hi,

>>>>> I am less concerned than Christer about the use of responses to INFO to carry ecall message bodies. The usage isn't specifically related to INFO, it is just following the standard mechanism from the >>>>additional-data draft for attaching data to arbitrary requests and responses. So I find attaching to an INFO response to be no worse than attaching to an INVITE response.
>>>>
>>>> If we think it's ok to carry bodies in INFO responses, then it 
>>>> should be brought to SIPCORE, and RFC 6086 should be updated. RFC 6086 currently says MUST NOT (the additional-data draft cannot override that rule).
>>>>
>>> While I'm not fond of the approach taken, I don't think it violates rfc6086. When a body is added to an INFO response, that body is not "associated with the INFO message". It is associated with a Call->>Info header field, as defined in the additional-info draft.
>>
> This is really about body parts that are present because they are referenced by a header field. It isn't much different by-value PIDF-LO bodies referenced from geoloc headers, or STIR signatures. (AFAIK > neither of those currently go in INFO requests or responses, but in principle they could.)
>
> In the use here, the body has nothing to do with the kind of message. It could in principle go in any sip request or response that happens to be going in the desired direction at the time.

Fair enough, but I don't think that applies to the eCall usage. In eCall the INFOs are explicitly used for carrying a protocol, and the message bodies we are talking about are associated with that protocol. And, in INFO requests the protocol message bodies are associated with an Info-Package.

Now, if I understand you correctly, anyone could use INFO responses to carry information associated with ANY Info Package - simply by using a different Content-Disposition value and calling it something else than Info-Package... If that's the case, we should update RFC 6086 to allow Info-Package bodies also in responses, so that people don't have to do hacks to get around it...

>They did make a special case when they send their body in INFO *requests*, in that they actually define and use an INFO package for the purpose. So they use a different Content-Disposition when >sending in INFO requests than they do everywhere else.

Sure, my point is that they send the same kind of information (read: same protocol) in INFO responses. It is not geolocation information, STIR signatures etc... It is information for which an Info-Package has been defined, and is used in the INFO requests.

Regards,

Christer

>>>> request, which makes things more verbose (something you 
>>>> specifically have been urging us to avoid doing) for no benefit.
>>>
>>>>>     As far as I know (please correct me if I'm wrong), we have 
>>>>> never agreed on such exception, and there has never been any 
>>>>> consulting with SIPCORE (there may be a good reason why it's not 
>>>>> allowed). I am not even sure draft-ecall can make such exception 
>>>>> without updating RFC 6086.
>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 16 Apr 2016 11:29:35 -0400

Christer,

I think we are agreeing on the spirit of the thing, while disagreeing on 
the details. My point is that IMO they are *technically* not violating 
anything. But that is me acting as a spec-lawyer for the defense. But 
from a broader perspective this is clearly an abuse of INFO.

I recognize that they don't want to use INFO for the whole thing because 
they want to minimize latence by putting the initial information in the 
INVITE.

I think a solution might be to separate this into two clearly distinct 
parts:

1) transmit the initial information in the INVITE, using the 
additional-data mechanism.

2) define a protocol over INFO for any further information during the 
call. This can use INFO in both directions, so no need to send data in 
INFO responses.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 16 Apr 2016 11:31:34 -0400

On 4/15/16 8:26 PM, Randall Gellens wrote:
>> requested type is then received, there is some ambiguity whether the
>> message was the expected response or an unsolicited message. This
>> could result in confusion.
>
> An eCall control block acknowledgment carries the CID of the data block
> being acknowledged.

I realize that. My concern was for those requests that don't get 
explicit ACK because the cause some other response. The problem being 
that there is no way to indicate that the resulting response was 
triggered by the request.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 16 Apr 2016 16:19:28 +0000

Hi,

> I think we are agreeing on the spirit of the thing, while disagreeing on the details. My point is that IMO they are *technically* not violating anything. 
> But that is me acting as a spec-lawyer for the defense. But from a broader perspective this is clearly an abuse of INFO.

I think we would set a dangerous prejudice. If we allow this, anyone could transport information associated with an Info Package in an INFO response, simply by using a different Content-Disposition value...

Also, section 3 or RFC 6086 says:

  "3.  UAs are allowed to enable both legacy INFO usages and Info
       Package usages as part of the same invite dialog usage, but UAs
       SHALL NOT mix legacy INFO usages and Info Package usages in order
       to transport the same application level information.  If
       possible, UAs SHALL prefer the usage of an Info Package."

And, IMHO, mixing legacy INFO usage and Info Package usage for transport of the same application level information is exactly what is happening in the eCall case: Info Package usage in INFO requests, and legacy usage in INFO responses....

Also, for those of us who have "been around" for a while, we know that the issues with legacy INFO were discussed for years in SIPCORE (and the WGs before that), and it took quite a while to agree the Info-Package mechanism too, as some people more or less wanted to deprecate INFO...

> I recognize that they don't want to use INFO for the whole thing because they want to minimize latence by putting the initial information in the INVITE.

I have no problem putting the initial information in the INVITE. People do that for other INFO usages too, e.g. DTMF.

>I think a solution might be to separate this into two clearly distinct parts:
>
> 1) transmit the initial information in the INVITE, using the additional-data mechanism.

I have no problem with that.

> 2) define a protocol over INFO for any further information during the call. This can use INFO in both directions, so no need to send data in INFO responses.

I don't think the protocol as such has to change. What has to change is that the protocol will only be carried in INFO requests.

Regards,

Christer

On 4/16/16 7:10 AM, Christer Holmberg wrote:
>> referenced by a header field. It isn't much different by-value 
>> PIDF-LO bodies referenced from geoloc headers, or STIR signatures. 
>> (AFAIK > neither of those currently go in INFO requests or responses, 
>> but in principle they could.)
>>
>>>>> INFO being the only message where emergency call data can't be 
>>>>> sent in its response.  This would force a reply to be sent in a 
>>>>> new INFO request, which makes things more verbose (something you 
>>>>>>      While not "illegal", I think that is bad protocol design, 
>>>>>> and not how INFO was supposed to be used. The reason we allowed 
>>>>>>      Section 9.2 of draft-ecall allows bodies associated with 
>>>>>> Info Packages in INFO responses. The text does recognize it is 
>>>>>> now allowed per RFC 6086, but gives some kind of "exception" for ecall usage.
>>>>>>

---

From: Randall Gellens <[email-masked]>
Date: Sat, 16 Apr 2016 12:38:50 -0700

At 11:31 AM -0400 4/16/16, Paul Kyzivat wrote:

> explicit ACK because the cause some other response. The problem 
> being that there is no way to indicate that the resulting response 
> was triggered by the request.

The only requests that don't get an explicit acknowledgment are 
requests to send a data block (e.g., another MSD).  Those are only 
sent by request (except for in the initial INVITE), so I'm not seeing 
the potential confusion.

-------------- Randomly selected tag: ---------------
Q:  Why do mountain climbers rope themselves together?
A:  To prevent the sensible ones from going home.

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 16 Apr 2016 17:35:58 -0400

> I don't think the protocol as such has to change. What has to change is that the protocol will only be carried in INFO requests.

Yes, that should work. It is what I had in mind.

	Thanks,
	Paul