Subject: [Ecrit] Summary of compromise proposal

From: Randall Gellens <[email-masked]>
Date: Thu, 1 Sep 2016 06:35:58 -0700

Hi Everyone,

I want to summarize the compromise that was proposed a couple weeks 
ago, for clarity:

- The metadata/control object is associated with the INFO package
- The MSD is not associated with the INFO package and is always sent 
using Call-Info to refer to it
- PSAP requests an updated MSD mid-call by sending an INFO containing 
a metadata/control object requesting an MSD, per the INFO package, 
with "Content-Disposition: info-package", and no Call-Info header 
field
- IVS sends an INFO with a metadata/control object containing an ACK 
with "success=true" indicating it sent the updated MSD
- IVS attaches an updated MSD in any convenient message; typically 
this will be the INFO with the ACK

This means that the INFO package defines a clean request/response 
protocol, while the MSD remains Additional Data per RFC 7852.

For the initial MSD (unchanged by the compromise), the MSD is 
included in the INVITE, referenced by a Call-Info header field and 
can be acknowledged in a final response (e.g. 200, 4xx, 6xx) using a 
metadata object referenced by a Call-Info header field.

The authors believe this compromise addresses the concerns raised, 
and provides a mechanism that can be easily extended in other 
documents (such as car-crash or future documents).

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
People demand freedom of speech to make up for the freedom of thought
which they avoid.                                       --Kierkegaard

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Sep 2016 14:41:03 +0000

Hi,

In case someone does not subscribe to the SIPCORE list, below is the compromise proposal I sent out earlier today:

---------------

While I highly appreciate Dale¹s input on the INFO issue, it seems like we won¹t get much wider input from the SIPCORE community.

So, in order to try to move forward, I would like to suggest a compromise proposal of my own. From a SIP message structure perspective it¹s basically what Dale has suggested (and what I assumed was already stated in draft-ecall-11), but with a different approach when it comes to the documenting.

First, the MSD is carried in an info package.

Second, the main text in draft-ecall talks about using the info package mechanism for carrying the MSD in INFO. The main text does not talk about using the additional data mechanism.

Third, and this is where my comprise proposal comes it, within the info package specification we add some text saying that while the semantics/context of the MSD MIME body is defined within the info package specification, in order to be aligned with the sending of MSD in non-INFO requests we use the content-disposition value reference-by and we include the Call-Info header field, as defined by Additional Data, in the INFO request.

That way, we make it clear that we are using the info package mechanism for transporting MSD in INFO, but it still allows for usage of Call-Info in INFO. 

Would people be ok with that?

INFO example:

Call-Info:   <cid:X>;purpose=emergencyCallData.eCall.MSD
Content-Type: multipart/mixed;boundary="theboundary"
Content-Disposition: info-package

--theboundary

Content-Type: application/emergencyCallData.eCall.MSD+per
Content-Dispostion: by-reference

<MSD content>

<theboundary--

---------------

I believe that more or less gives everyone what they want: we use an Info Package also for MSD, but we allow inclusion of the Call-Info header field in the INFOs carrying the MSDs.

Regards,

Christer

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Randall Gellens
Sent: 01 September 2016 16:36
To: [email-masked]
Subject: [Ecrit] Summary of compromise proposal

Hi Everyone,

I want to summarize the compromise that was proposed a couple weeks ago, for clarity:

- The metadata/control object is associated with the INFO package
- The MSD is not associated with the INFO package and is always sent using Call-Info to refer to it
- PSAP requests an updated MSD mid-call by sending an INFO containing a metadata/control object requesting an MSD, per the INFO package, with "Content-Disposition: info-package", and no Call-Info header field
- IVS sends an INFO with a metadata/control object containing an ACK with "success=true" indicating it sent the updated MSD
- IVS attaches an updated MSD in any convenient message; typically this will be the INFO with the ACK

This means that the INFO package defines a clean request/response protocol, while the MSD remains Additional Data per RFC 7852.

For the initial MSD (unchanged by the compromise), the MSD is included in the INVITE, referenced by a Call-Info header field and can be acknowledged in a final response (e.g. 200, 4xx, 6xx) using a metadata object referenced by a Call-Info header field.

The authors believe this compromise addresses the concerns raised, and provides a mechanism that can be easily extended in other documents (such as car-crash or future documents).

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- People demand freedom of speech to make up for the freedom of thought
which they avoid.                                       --Kierkegaard

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: <[email-masked]>
Date: Thu, 1 Sep 2016 15:48:04 +0000

Hi Randy,
we would like to support your proposal. Even I would have liked to see the Call-Info header within the INFO for the reasons I described on the SIPCORE list.

Best Regards

Roland 

-----Ursprüngliche Nachricht-----
Von: Ecrit [mailto:[email-masked]] Im Auftrag von Randall Gellens
Gesendet: Donnerstag, 1. September 2016 15:36
An: [email-masked]
Betreff: [Ecrit] Summary of compromise proposal

Hi Everyone,

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Sep 2016 15:51:48 +0000

Hi,

Please note that my proposal allows Call-Info in INFO, while still using an info package.

I think that more or less gives everyone what they want.

Regards,

Christer

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 01 September 2016 18:48
To: [email-masked]; [email-masked]
Subject: Re: [Ecrit] Summary of compromise proposal

Hi Randy,

Best Regards

Roland 

-----Ursprüngliche Nachricht-----
Von: Ecrit [mailto:[email-masked]] Im Auftrag von Randall Gellens
Gesendet: Donnerstag, 1. September 2016 15:36
An: [email-masked]
Betreff: [Ecrit] Summary of compromise proposal

Hi Everyone,

---

From: <[email-masked]>
Date: Thu, 1 Sep 2016 16:08:55 +0000

Hi Christer,
your proposal is straight forward that you would like to use only one transport mechanism for MSD. 

To make my mid up I have some questions.

For me it would be very important that I have the Information as soon as possible within the PSAP. Question is if a couple of milliseconds more until the INFO arrives is OK?

Next Question does each eCall will have extensive MSD exchange, so that more than one MSD Block is sent?

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Ecrit [mailto:[email-masked]] Im Auftrag von Christer Holmberg
Gesendet: Donnerstag, 1. September 2016 16:41
An: Randall Gellens; [email-masked]
Betreff: Re: [Ecrit] Summary of compromise proposal

Hi,

---------------

INFO example:

--theboundary

<MSD content>

<theboundary--

---------------

Regards,

Christer

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Randall Gellens
Sent: 01 September 2016 16:36
To: [email-masked]
Subject: [Ecrit] Summary of compromise proposal

Hi Everyone,

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 1 Sep 2016 16:17:39 +0000

Hi,

>your proposal is straight forward that you would like to use only one transport >mechanism for MSD. 

Well, specification wise we would use an info package for transporting MSD in INFO, but both the by-reference content disposition value and the  Call-Info header field for the MSD body would be there for those who need it (for whatever purpose), so it would look like the INVITE mechanism.

>For me it would be very important that I have the Information as soon as possible >within the PSAP. Question is if a couple of milliseconds more until the INFO arrives is >OK?

I don't think we in the IETF spec can specify how many milliseconds it will take for the information to traverse the network and be processed by devices. That you need to discuss with your vendors and network designers.

>Next Question does each eCall will have extensive MSD exchange, so that more than >one MSD Block is sent?

The PSAP can request the device for a new MSD exchange. But it is not expected to happen very frequently, and if it happens it will mostly be once per call. At least that is my understanding from what Randall and others have said.

Regards,

Christer

-----Ursprüngliche Nachricht-----
Von: Ecrit [mailto:[email-masked]] Im Auftrag von Christer Holmberg
Gesendet: Donnerstag, 1. September 2016 16:41
An: Randall Gellens; [email-masked]
Betreff: Re: [Ecrit] Summary of compromise proposal

Hi,

---------------

INFO example:

--theboundary

<MSD content>

<theboundary--

---------------

Regards,

Christer

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Randall Gellens
Sent: 01 September 2016 16:36
To: [email-masked]
Subject: [Ecrit] Summary of compromise proposal

Hi Everyone,

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Sat, 3 Sep 2016 12:48:46 +0000

If the MSD is being sent in INFO requests, it is sent according to the Info package, and therefore you cannot state " The MSD is not associated with the INFO package and is always sent using Call-Info to refer to it " unless here you are referring to only the MSD in the initial INVITE.

Keith

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 01 September 2016 16:48
To: [email-masked]; [email-masked]
Subject: Re: [Ecrit] Summary of compromise proposal

Hi Randy,

Best Regards

Roland 

-----Ursprüngliche Nachricht-----
Von: Ecrit [mailto:[email-masked]] Im Auftrag von Randall Gellens
Gesendet: Donnerstag, 1. September 2016 15:36
An: [email-masked]
Betreff: [Ecrit] Summary of compromise proposal

Hi Everyone,

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 8 Sep 2016 12:42:49 +0200

Hi Randy,

I am OK with this compromise.

Ciao
Hannes

On 09/01/2016 03:35 PM, Randall Gellens wrote:
> - PSAP requests an updated MSD mid-call by sending an INFO containing a
> metadata/control object requesting an MSD, per the INFO package, with
> "Content-Disposition: info-package", and no Call-Info header field
> For the initial MSD (unchanged by the compromise), the MSD is included
> in the INVITE, referenced by a Call-Info header field and can be
> acknowledged in a final response (e.g. 200, 4xx, 6xx) using a metadata
> object referenced by a Call-Info header field.
>
> The authors believe this compromise addresses the concerns raised, and
> provides a mechanism that can be easily extended in other documents
> (such as car-crash or future documents).
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 8 Sep 2016 10:50:15 +0000

I am not OK with Randal's compromise solution.

MSD is related to eCall so I don't see why it should not be associated with the eCall info-package.

I support Christer's compromise solution.

Kind regards

Ivo

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, September 08, 2016 12:43 PM
To: Randall Gellens; [email-masked]
Subject: Re: [Ecrit] Summary of compromise proposal

Hi Randy,

Ciao
Hannes

On 09/01/2016 03:35 PM, Randall Gellens wrote:
> with

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Thu, 8 Sep 2016 11:29:03 +0000

I also support Christer's compromise

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Ivo Sedlacek
Sent: Thursday, September 08, 2016 6:50 AM
To: Hannes Tschofenig <[email-masked]>; Randall Gellens <[email-masked]>; [email-masked]
Subject: Re: [Ecrit] Summary of compromise proposal

Kind regards

Ivo

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, September 08, 2016 12:43 PM
To: Randall Gellens; [email-masked]
Subject: Re: [Ecrit] Summary of compromise proposal

Hi Randy,

Ciao
Hannes

---

From: <[email-masked]>
Date: Thu, 8 Sep 2016 12:20:04 +0000

Hi Ivo,
I do not understand what you will say with your statement.

Initial MSD is sent with INVITE and an update of MSD is done via INFO.

So it is only the update of the MSD data.

So from my understanding it is the same as Christer stated within his Statement.

Or what do you mean?
 
Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Ecrit [mailto:[email-masked]] Im Auftrag von Ivo Sedlacek
Gesendet: Donnerstag, 8. September 2016 12:50
An: Hannes Tschofenig; Randall Gellens; [email-masked]
Betreff: Re: [Ecrit] Summary of compromise proposal

Kind regards

Ivo

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, September 08, 2016 12:43 PM
To: Randall Gellens; [email-masked]
Subject: Re: [Ecrit] Summary of compromise proposal

Hi Randy,

Ciao
Hannes

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 8 Sep 2016 12:29:44 +0000

Let me be clearer:

	MSD is related to eCall so >>when updated MSD is sent via INFO from UE to PSAP<<, I don't see why the MSD should not be associated with the eCall info-package.

Kind regards

ivo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, September 08, 2016 2:20 PM
To: Ivo Sedlacek; [email-masked]; [email-masked]; [email-masked]
Subject: AW: [Ecrit] Summary of compromise proposal

Hi Ivo,

Or what do you mean?
 
Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Ecrit [mailto:[email-masked]] Im Auftrag von Ivo Sedlacek
Gesendet: Donnerstag, 8. September 2016 12:50
An: Hannes Tschofenig; Randall Gellens; [email-masked]
Betreff: Re: [Ecrit] Summary of compromise proposal

Kind regards

Ivo

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, September 08, 2016 12:43 PM
To: Randall Gellens; [email-masked]
Subject: Re: [Ecrit] Summary of compromise proposal

Hi Randy,

Ciao
Hannes

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Sep 2016 13:00:14 +0000

Hi,

I obviously also support my proposal, because it gives everyone most of
what they want.

Regards,

Christer

On 08/09/16 15:29, "Ecrit on behalf of Ivo Sedlacek"
<[email-masked] on behalf of [email-masked]> wrote:

>	MSD is related to eCall so >>when updated MSD is sent via INFO from UE
>to PSAP<<, I don't see why the MSD should not be associated with the
>eCall info-package.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 8 Sep 2016 10:08:16 -0400

While I have been fairly vocal on this, I find both Randal's & 
Christer's compromises to acceptable. So I am not going to express a 
preference between them.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Thu, 8 Sep 2016 11:13:14 -0700

Hi Ivo,

I discussed with the other authors the proposal that Christer (and I 
think also Dale, independently) suggested, which as I understand it 
is that the MSD is included in the INFO package registration, and is 
sent with a Call-Info header referencing it and a Content-Disposition 
of By-Reference, both in INVITE and INFO.  All the authors have 
agreed to adopt this as the way forward.  As Christer put it, this 
gives both sides what they want (MSD is part of the INFO package, and 
always has a Call-Info header field pointing to it).  I will modify 
the draft along the lines Christer suggested (especially with 
editorial text pointing this out, which I think will help provide 
clarity).  I will also make the various (unrelated) fixes pointed out 
by Dale, which I appreciate his finding.  I thank Christer, Dale, and 
others for the discussion and suggestions, and am happy that we have 
a resolution agreeable to everyone.

-------------- Randomly selected tag: ---------------
When bad men combine, the good must associate; else they will fall, one
by one, an unpitied sacrifice in a contemptible struggle.
                                             --Edmund Burke (1729-1797)