Subject: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 10 Aug 2016 12:54:07 +0000

I did not properly address a response to Ivo and Randy to include the working group, so I’m forwarding this part of the discussion back to the group.

I think, Ivo, that you are being way too picky about whether the report is information about the callee or the control body is information about the caller.  I think it’s close enough that we should not use that as the reason we don’t make all of these instances of additional data uniformly.

I acknowledge that it’s not needed with the INFO package, but I think it does no harm, and makes the entire mechanism consistent with all the other parts of additional data, which you acknowledge that the actual eCall data clearly is.

Brian

Begin forwarded message:

From: Ivo Sedlacek <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)
Date: August 10, 2016 at 3:32:00 AM EDT
To: "Rosen, Brian" <[email-masked]<mailto:[email-masked]>>, Randall Gellens <[email-masked]<mailto:[email-masked]>>

Hello,

In the response to the INVITE request, the Call-Info points to the application/emergencyCallData.eCall.control+xml body. This body contains a delivery report for the MSD sent in INVITE request. This is NOT information about callee. Thus, RFC3261 semantic is not fulfilled.

In the INFO request, the Call-Info points to the application/emergencyCallData.eCall.control+xml body. This body describes an action to be performed at the remote UE. This is NOT information about the sender of the INFO request. Thus, RFC3261 semantic is not fulfilled. Also, as other people indicated, this is not needed with info package mechanism.

Kind regards

Ivo

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, August 09, 2016 11:22 PM
To: Randall Gellens
Cc: Ivo Sedlacek
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

I strongly agree.

It’s small cost and I think a substantial benefit to treat all the blocks as additional data blocks, put them in the registry, etc.  INFO is a solution to a mid-call need to send additional data, and we should treat it that way in my opinion.

We can state that the block reference in the INFO package must match that in the Call-Info.

Brian

On Aug 9, 2016, at 1:22 PM, Randall Gellens <[email-masked]<mailto:[email-masked]>> wrote:

I prefer to keep the use of Call-Info for all three cases (INVITE, response, INFO) to maintain compatibility with RFC 7852 (Additional Data) and car-crash (North American NG-AACN).  I see benefit without any real-world harm in using Call-Info even if not strictly necessary (e.g., INFO).

--Randy

At 2:23 PM +0000 8/9/16, Ivo Sedlacek wrote:

Hello,

given the use case raised by Roland and clarified by Paul, let me suggest the following compromise:

Call-Info included in an INVITE request and pointing to the application/emergencyCallData.eCall.MSD+per body of the INVITE request is kept, while Call-Info in a response to the INVITE request and in an INFO request is removed.

Does this work for everyone?

Kind regards

Ivo Sedlacek

_______________________________________________
Ecrit mailing list
[email-masked]<mailto:[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: --------------- I hold that the
very purpose of existence is to reconcile the glowing opinion we have
of ourselves with the terrible things
that other people say about us.               --Quentin Crisp

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Aug 2016 13:09:19 +0000

Hi,

…

>I acknowledge that it’s not needed with the INFO package, but I think it does no harm, and makes the entire mechanism consistent with all the other parts of additional data

No, it doesn’t. We don’t use the “by-reference” disposition type in INFO, so there would not be a reference between the Call-Info value and the message body. Message bodies associated with info packages have the “info-package” disposition type, and the semantics are covered by the info package specification.

So, the information is useless.

Regards,

Christer

Begin forwarded message:

Hello,

Kind regards

Ivo

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, August 09, 2016 11:22 PM
To: Randall Gellens
Cc: Ivo Sedlacek
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

I strongly agree.

Brian

--Randy

Hello,

Kind regards

Ivo Sedlacek

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 10 Aug 2016 13:27:26 +0000

Hello,

I am not picky - I solely point out a discrepancy between RFC3261 definition of semantic of Call-Info and draft-ietf-ecrit-ecall-11 usage of Call-Info.

It would be a dangerous precedent if a working group starts modifying semantic of header fields defined in RFC3261.

I suggest we bring this issue to SIPCORE to settle whether draft-ietf-ecrit-ecall-11 usage of Call-Info is aligned with RFC3261 or not.

Kind regards

Ivo

From: Ecrit [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Wednesday, August 10, 2016 2:54 PM
To: Emergency Context Resolution with Internet Technologies Discussion List
Subject: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Brian

Begin forwarded message:

Hello,

Kind regards

Ivo

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, August 09, 2016 11:22 PM
To: Randall Gellens
Cc: Ivo Sedlacek
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

I strongly agree.

Brian

--Randy

Hello,

Kind regards

Ivo Sedlacek

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Aug 2016 15:22:12 +0000

Hi,

>I don’t believe it is “useless”.
>
>I believe it is dangerous because it introduces an interaction between two separate protocol mechanisms.

Correct, and I earlier said that we’d have to define what happens if there e.g. is a missmatch between the mechanisms.

What I meant by “useless” is that since the content disposition type of the INFO message bodies are “info package”, there is no reference to the Call-Info header fields – the semantics must be defined in the info package description.

Regards,

Christer

From: Ecrit [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 10 August 2016 14:09
To: Rosen, Brian; Emergency Context Resolution with Internet Technologies Discussion List
Subject: Re: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

Hi,

…

Regards,

Christer

Begin forwarded message:

Hello,

Kind regards

Ivo

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, August 09, 2016 11:22 PM
To: Randall Gellens
Cc: Ivo Sedlacek
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

I strongly agree.

Brian

--Randy

Hello,

Kind regards

Ivo Sedlacek

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 10 Aug 2016 15:11:53 +0000

I don't believe it is "useless".

(This is not precluding the use for other purposes for Call-Info, but those purposes need to be made clear, and in accordance with RFCs)

Keith

Hi,

...

>I acknowledge that it's not needed with the INFO package, but I think it does no harm, and makes the entire mechanism consistent with all the other parts of additional data

No, it doesn't. We don't use the "by-reference" disposition type in INFO, so there would not be a reference between the Call-Info value and the message body. Message bodies associated with info packages have the "info-package" disposition type, and the semantics are covered by the info package specification.

Regards,

Christer

Begin forwarded message:

Hello,

Kind regards

Ivo

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, August 09, 2016 11:22 PM
To: Randall Gellens
Cc: Ivo Sedlacek
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

I strongly agree.

It's small cost and I think a substantial benefit to treat all the blocks as additional data blocks, put them in the registry, etc.  INFO is a solution to a mid-call need to send additional data, and we should treat it that way in my opinion.

Brian

--Randy

Hello,

Kind regards

Ivo Sedlacek

---

From: Randall Gellens <[email-masked]>
Date: Wed, 10 Aug 2016 13:36:56 -0700

implementations can mess up in an almost infinite 
variety of ways.  Call-Info could indicate a 
different block than actually present.  The MIME 
type of a body part could be incorrect.  A data 
object could be malformed.  Since our context is 
emergency calls, in general the call won't be 
failed and the SIP message won't be rejected. 
RFC 7852 contains language regarding this.

--Randy

At 3:22 PM +0000 8/10/16, Christer Holmberg wrote:

>   >I believe it is dangerous because it 
> introduces an interaction between two separate 
> protocol mechanisms.
>
>
>  Correct, and I earlier said that we'd have to 
> define what happens if there e.g. is a 
> missmatch between the mechanisms.
>
>  What I meant by "useless" is that since the 
> content disposition type of the INFO message 
> bodies are "info package", there is no 
> reference to the Call-Info header fields - the 
> semantics must be defined in the info package 
> description.
>
>  Regards,
>
>  Christer
>
>
>
>
>  From: Ecrit 
> [<mailto:[email-masked]>mailto:[email-masked]] 
> On Behalf Of Christer Holmberg
>  To: Rosen, Brian; Emergency Context Resolution 
> with Internet Technologies Discussion List
>  Subject: Re: [Ecrit] Fwd: 
> draft-ietf-ecrit-ecall-11- Call-Info usage not 
> aligned with RFC3261 (was RE: 
> draft-ietf-ecrit-ecall-11- Call-Info usage 
> brings no value)
>
>
>
>  Hi,
>
>
>
>  Š
>
>
>
>   >I acknowledge that it's not needed with the 
> INFO package, but I think it does no harm, and 
> makes the entire mechanism consistent with all 
> the other parts of additional data
>
>
>
>  No, it doesn't. We don't use the "by-reference" 
> disposition type in INFO, so there would not be 
> a reference between the Call-Info value and the 
> message body. Message bodies associated with 
> info packages have the "info-package" 
> disposition type, and the semantics are covered 
> by the info package specification.
>
>
>
>  From: Ivo Sedlacek 
> <<mailto:[email-masked]>[email-masked]>
>
>  Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- 
> Call-Info usage not aligned with RFC3261 (was 
> RE: draft-ietf-ecrit-ecall-11- Call-Info usage 
> brings no value)
>
>  To: "Rosen, Brian" 
> <<mailto:[email-masked]>[email-masked]>, 
> Randall Gellens 
> <<mailto:[email-masked]>[email-masked]>
>
>
>
>  Hello,
>
>  In the response to the INVITE request, the 
> Call-Info points to the 
> application/emergencyCallData.eCall.control+xml 
> body. This body contains a delivery report for 
> the MSD sent in INVITE request. This is NOT 
> information about callee. Thus, RFC3261 
> semantic is not fulfilled.
>
>  In the INFO request, the Call-Info points to 
> the 
> application/emergencyCallData.eCall.control+xml 
> body. This body describes an action to be 
> performed at the remote UE. This is NOT 
> information about the sender of the INFO 
> request. Thus, RFC3261 semantic is not 
> fulfilled. Also, as other people indicated, 
> this is not needed with info package mechanism.
>
>  Kind regards
>
>  Ivo
>
>  From: Rosen, Brian 
> [<mailto:[email-masked]>mailto:[email-masked]]
>  Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-11- 
> Call-Info usage not aligned with RFC3261 (was 
> RE: draft-ietf-ecrit-ecall-11- Call-Info usage 
> brings no value)
>
>  I strongly agree.
>
>  It's small cost and I think a substantial 
> benefit to treat all the blocks as additional 
> data blocks, put them in the registry, etc. 
>  INFO is a solution to a mid-call need to send 
> additional data, and we should treat it that 
> way in my opinion.
>
>  We can state that the block reference in the 
> INFO package must match that in the Call-Info.
>
>  Brian
>
>  On Aug 9, 2016, at 1:22 PM, Randall Gellens 
> <<mailto:[email-masked]>[email-masked]> 
> wrote:
>
>  I prefer to keep the use of Call-Info for all 
> three cases (INVITE, response, INFO) to 
> maintain compatibility with RFC 7852 
> (Additional Data) and car-crash (North American 
> NG-AACN).  I see benefit without any real-world 
> harm in using Call-Info even if not strictly 
> necessary (e.g., INFO).
>
>  --Randy
>
>  given the use case raised by Roland and 
> clarified by Paul, let me suggest the following 
> compromise:
>
>  Call-Info included in an INVITE request and 
> pointing to the 
> application/emergencyCallData.eCall.MSD+per 
> body of the INVITE request is kept, while 
> Call-Info in a response to the INVITE request 
> and in an INFO request is removed.
>
>  <mailto:[email-masked]>[email-masked]
> 
> <https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit
>
>
>
>  --
>  Randall Gellens
>  [email-masked]

-------------- Randomly selected tag: ---------------
Ever notice that people who are late are much jollier
than the people who have to wait for them?

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 10 Aug 2016 21:30:45 +0000

I think we have to be absolutely clear. RFC 7852 <underline> DOES NOT <stop underline> apply in the case of the data element attached to an INFO package in support of ecrit.

I thought we had reached agreement that when INFO was used, then an Info package would be defined and the rules for supporting an Info Package would be used. Attempting to suggest that a Call-Info is used appears to me to persisting in the previous attempt to reuse INFO in support of something that is not an Info package.

In respect of an Info-Package usage, Call-Info has no semantic meaning, and to me that is an implicit message to any protocol implementor never to include it.

Of course you may be trying to hint that somehow the use of the Call-Info has some semantic meaning across messages (following some of Brian's comments on same usage from one message to another), but that semantic does not exist in RFC 7852 and has never been defined. RFC 7852 usage applies only to the message in which it appears. Also possibly, you might be thinking of a use case where additional data is used in parallel to to a separate Info-Package, but I have the greatest difficulty in identifying that as a use case as opposed to where two separate and parallel Info packages might have been used.

Regards

Keith

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: 10 August 2016 21:37
To: Christer Holmberg; Drage, Keith (Nokia - GB); Rosen, Brian; Emergency Context Resolution with Internet Technologies Discussion List
Subject: Re: [Ecrit] Fwd: draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 (was RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)

implementations can mess up in an almost infinite variety of ways.  Call-Info could indicate a different block than actually present.  The MIME type of a body part could be incorrect.  A data object could be malformed.  Since our context is emergency calls, in general the call won't be failed and the SIP message won't be rejected. 
RFC 7852 contains language regarding this.

--Randy

At 3:22 PM +0000 8/10/16, Christer Holmberg wrote:

>   >I believe it is dangerous because it introduces an interaction 
> between two separate protocol mechanisms.
>
>
>  Correct, and I earlier said that we'd have to define what happens if 
> there e.g. is a missmatch between the mechanisms.
>
>  What I meant by "useless" is that since the content disposition type 
> of the INFO message bodies are "info package", there is no reference 
> to the Call-Info header fields - the semantics must be defined in the 
> info package description.
>
>  Regards,
>
>  Christer
>
>
>
>
>  From: Ecrit
> draft-ietf-ecrit-ecall-11- Call-Info usage not aligned with RFC3261 
> (was RE:
> draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)
>
>
>
>  Hi,
>
>
>
>  Š
>
>
>
>   >I acknowledge that it's not needed with the INFO package, but I 
> think it does no harm, and makes the entire mechanism consistent with 
> all the other parts of additional data
>
>
>
> disposition type in INFO, so there would not be a reference between 
> the Call-Info value and the message body. Message bodies associated 
> with info packages have the "info-package"
> disposition type, and the semantics are covered by the info package 
> specification.
>
>
>
>  Subject: RE: [Ecrit] draft-ietf-ecrit-ecall-11- Call-Info usage not 
> aligned with RFC3261 (was
> RE: draft-ietf-ecrit-ecall-11- Call-Info usage brings no value)
>

---

From: Randall Gellens <[email-masked]>
Date: Wed, 10 Aug 2016 14:48:55 -0700

RFC 7852 is not prohibited from applying to INFO. 
Yes, we agree that when INFO is used, we 
(underline)also(stop underline) need to include 
an INFO package.  That's in addition, not instead 
of.

At 9:30 PM +0000 8/10/16, Keith (Nokia - GB) Drage wrote:

>  I think we have to be absolutely clear. RFC 
> 7852 <underline> DOES NOT <stop underline> 
> apply in the case of the data element attached 
> to an INFO package in support of ecrit.
>
>  I thought we had reached agreement that when 
> INFO was used, then an Info package would be 
> defined and the rules for supporting an Info 
> Package would be used. Attempting to suggest 
> that a Call-Info is used appears to me to 
> persisting in the previous attempt to reuse 
> INFO in support of something that is not an 
> Info package.
>
>  In respect of an Info-Package usage, Call-Info 
> has no semantic meaning, and to me that is an 
> implicit message to any protocol implementor 
> never to include it.
>
>  Of course you may be trying to hint that 
> somehow the use of the Call-Info has some 
> semantic meaning across messages (following 
> some of Brian's comments on same usage from one 
> message to another), but that semantic does not 
> exist in RFC 7852 and has never been defined. 
> RFC 7852 usage applies only to the message in 
> which it appears. Also possibly, you might be 
> thinking of a use case where additional data is 
> used in parallel to to a separate Info-Package, 
> but I have the greatest difficulty in 
> identifying that as a use case as opposed to 
> where two separate and parallel Info packages 
> might have been used.
>
>  Regards
>
>  Keith
>
>  To: Christer Holmberg; Drage, Keith (Nokia - 
> GB); Rosen, Brian; Emergency Context Resolution 
>  implementations can mess up in an almost 
> infinite variety of ways.  Call-Info could 
> indicate a different block than actually 
> present.  The MIME type of a body part could be 
> incorrect.  A data object could be malformed. 
> Since our context is emergency calls, in 
> general the call won't be failed and the SIP 
> message won't be rejected.
>>   ·

-------------- Randomly selected tag: ---------------
Anything labeled "NEW" and/or "IMPROVED" isn't.  The label means the
price went up.  The label "ALL NEW", "COMPLETELY NEW", or "GREAT NEW"
means the price went way up.