From nobody Thu Sep  1 06:57:12 2016
Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCCF12D932 for <ecrit@ietfa.amsl.com>; Thu,  1 Sep 2016 06:57:11 -0700 (PDT)
X-Quarantine-ID: <arZ1UGiy2Eac>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arZ1UGiy2Eac for <ecrit@ietfa.amsl.com>; Thu,  1 Sep 2016 06:57:10 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDBF12DC63 for <ecrit@ietf.org>; Thu,  1 Sep 2016 06:36:05 -0700 (PDT)
Received: from [172.20.10.255] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 1 Sep 2016 06:36:03 -0700
Mime-Version: 1.0
Message-Id: <p06240600d3eddf1b05c2@[172.20.10.255]>
X-Mailer: Eudora for Mac OS X
Date: Thu, 1 Sep 2016 06:35:58 -0700
To: ecrit@ietf.org
From: Randall Gellens <rg+ietf@randy.pensive.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/POsP-lHm36BRKYrXelSCHE8jFng>
Subject: [Ecrit] Summary of compromise proposal
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Sep 2016 13:57:12 -0000

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 nobody Thu Sep  1 06:58:05 2016
Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A883E12D7FD for <ecrit@ietfa.amsl.com>; Thu,  1 Sep 2016 06:58:03 -0700 (PDT)
X-Quarantine-ID: <I8uykpOqrYpm>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8uykpOqrYpm for <ecrit@ietfa.amsl.com>; Thu,  1 Sep 2016 06:58:01 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7E56212DD09 for <ecrit@ietf.org>; Thu,  1 Sep 2016 06:37:41 -0700 (PDT)
Received: from [172.20.10.255] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 1 Sep 2016 06:37:41 -0700
Mime-Version: 1.0
Message-Id: <p06240601d3eddf841e69@[172.20.10.255]>
In-Reply-To: <87twe21f43.fsf@hobgoblin.ariadne.com> <87k2ey1dvt.fsf@hobgoblin.ariadne.com>
References: <87twe21f43.fsf@hobgoblin.ariadne.com> <87k2ey1dvt.fsf@hobgoblin.ariadne.com>
X-Mailer: Eudora for Mac OS X
Date: Thu, 1 Sep 2016 06:37:37 -0700
To: worley@ariadne.com (Dale R. Worley), ecrit@ietf.org
From: Randall Gellens <rg+ietf@randy.pensive.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/3OByabS2hw7Ju--8Svvz-PPfb0k>
Subject: Re: [Ecrit] Errata and queries re draft-ietf-ecrit-ecall-11, etc.
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Sep 2016 13:58:04 -0000

Hi Dale,

Thanks for catching these things.  I'll fix them in the next rev.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
If people don't know what you're doing, they don't know what you're
doing wrong.         --Sir Arnold Robinson, _Yes,_Minister_


From nobody Thu Sep  1 07:41:14 2016
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E9512D9C0 for <ecrit@ietfa.amsl.com>; Thu,  1 Sep 2016 07:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhyqhEMEGjo9 for <ecrit@ietfa.amsl.com>; Thu,  1 Sep 2016 07:41:11 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B38BC12D581 for <ecrit@ietf.org>; Thu,  1 Sep 2016 07:41:10 -0700 (PDT)
X-AuditID: c1b4fb3a-0618b980000009bd-1e-57c83e042f8c
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by  (Symantec Mail Security) with SMTP id C4.94.02493.40E38C75; Thu,  1 Sep 2016 16:41:09 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0301.000; Thu, 1 Sep 2016 16:41:03 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Randall Gellens <rg+ietf@randy.pensive.org>, "ecrit@ietf.org" <ecrit@ietf.org>
Thread-Topic: [Ecrit] Summary of compromise proposal
Thread-Index: AQHSBFi+0aHX9V43e0SFdIcPUtJ4l6BktHlg
Date: Thu, 1 Sep 2016 14:41:03 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC7F33C@ESESSMB209.ericsson.se>
References: <p06240600d3eddf1b05c2@[172.20.10.255]>
In-Reply-To: <p06240600d3eddf1b05c2@[172.20.10.255]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7ky6r3Ylwg55mLovGRU9ZLb4/72J0 YPJYsuQnk8fWO49ZApiiuGxSUnMyy1KL9O0SuDIOvrnJVLBIvmL57l7mBsbJkl2MnBwSAiYS B7ZtY+xi5OIQEljPKHH9ywI2CGcxo8TFTbOYuxg5ONgELCS6/2mDmCICIRIt77lAeoUFjCXe 7brFAmKLAM1Z2nieCcI2klj6bB4riM0ioCJx6cQBsDivgK/Em9MzwOJCQL3X33eA9XIC9Z5c 8R+shlFATOL7qTVgNrOAuMStJ/OZIO4UkFiy5zwzhC0q8fLxP1YIW0micckTVoh6PYkbU6ew QdjaEssWvmaG2CsocXLmE5YJjCKzkIydhaRlFpKWWUhaFjCyrGIULU4tLs5NNzLSSy3KTC4u zs/Ty0st2cQIjIaDW35b7WA8+NzxEKMAB6MSD2+CyYlwIdbEsuLK3EOMEhzMSiK8qy2BQrwp iZVVqUX58UWlOanFhxilOViUxHn9XyqGCwmkJ5akZqemFqQWwWSZODilGhhLnnHU7QhbNpvR akn9tWBXjYdno/iWZxffV3IQPBWm5zQtge1sl/+KW3uCzzFMLut5N+Pm3xumBbJf3QW9dnPH OnxurZp5kVNm98l4jb2XdhbuX1CoFNy37Lbf2scpTrOSn+urFNw6KfT29QqrbTK5TGk1ZUyR tS8ueXEI7LNvf2+X///TtzYlluKMREMt5qLiRAAqxtsGggIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/4xkOSbCweunNqatn90UBeN4JUEc>
Subject: Re: [Ecrit] Summary of compromise proposal
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Sep 2016 14:41:13 -0000

Hi,

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

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

While I highly appreciate Dale=B9s input on the INFO issue, it seems like w=
e won=B9t get much wider input from the SIPCORE community.

So, in order to try to move forward, I would like to suggest a compromise p=
roposal of my own. From a SIP message structure perspective it=B9s basicall=
y what Dale has suggested (and what I assumed was already stated in draft-e=
call-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 mec=
hanism for carrying the MSD in INFO. The main text does not talk about usin=
g the additional data mechanism.

Third, and this is where my comprise proposal comes it, within the info pac=
kage 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 IN=
FO.=20

Would people be ok with that?


INFO example:


Call-Info:   <cid:X>;purpose=3DemergencyCallData.eCall.MSD
Content-Type: multipart/mixed;boundary=3D"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 P=
ackage also for MSD, but we allow inclusion of the Call-Info header field i=
n the INFOs carrying the MSDs.

Regards,

Christer



-----Original Message-----
From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens
Sent: 01 September 2016 16:36
To: ecrit@ietf.org
Subject: [Ecrit] Summary of compromise proposal

Hi Everyone,

I want to summarize the compromise that was proposed a couple weeks ago, fo=
r 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 met=
adata/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=3Dtrue" indicating it sent the updated MSD
- IVS attaches an updated MSD in any convenient message; typically this wil=
l 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 t=
he INVITE, referenced by a Call-Info header field and can be acknowledged i=
n 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 prov=
ides a mechanism that can be easily extended in other documents (such as ca=
r-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
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


From nobody Thu Sep  1 08:49:10 2016
Return-Path: <R.Jesske@telekom.de>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB6F12DA64 for <ecrit@ietfa.amsl.com>; Thu,  1 Sep 2016 08:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.768
X-Spam-Level: 
X-Spam-Status: No, score=-4.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0ctUcrZ_mHP for <ecrit@ietfa.amsl.com>; Thu,  1 Sep 2016 08:49:06 -0700 (PDT)
Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4725512DA61 for <ecrit@ietf.org>; Thu,  1 Sep 2016 08:49:05 -0700 (PDT)
Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail91.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 01 Sep 2016 17:49:03 +0200
X-IronPort-AV: E=Sophos;i="5.30,268,1470693600"; d="scan'208";a="525344222"
Received: from he105661.emea1.cds.t-internal.com ([10.169.119.57]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 01 Sep 2016 17:48:52 +0200
Received: from HE105660.EMEA1.cds.t-internal.com (10.169.119.56) by HE105661.emea1.cds.t-internal.com (10.169.119.57) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Sep 2016 17:48:04 +0200
Received: from HE105660.EMEA1.cds.t-internal.com ([fe80::c5cd:6c67:9f4d:7318]) by HE105660.emea1.cds.t-internal.com ([fe80::c5cd:6c67:9f4d:7318%26]) with mapi id 15.00.1178.000; Thu, 1 Sep 2016 17:48:04 +0200
From: <R.Jesske@telekom.de>
To: <rg+ietf@randy.pensive.org>, <ecrit@ietf.org>
Thread-Topic: [Ecrit] Summary of compromise proposal
Thread-Index: AQHSBFi/FCptCKxyuUSXXzAMQz0RDqBkx24A
Date: Thu, 1 Sep 2016 15:48:04 +0000
Message-ID: <f934f494a59c452aab7cb27c92767025@HE105660.emea1.cds.t-internal.com>
References: <p06240600d3eddf1b05c2@[172.20.10.255]>
In-Reply-To: <p06240600d3eddf1b05c2@[172.20.10.255]>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.213.93.147]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/M6XFvRhLhcMTRIHcu9yKrqp3TNM>
Subject: Re: [Ecrit] Summary of compromise proposal
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Sep 2016 15:49:09 -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=20

-----Urspr=FCngliche Nachricht-----
Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Randall Gellens
Gesendet: Donnerstag, 1. September 2016 15:36
An: ecrit@ietf.org
Betreff: [Ecrit] Summary of compromise proposal

Hi Everyone,

I want to summarize the compromise that was proposed a couple weeks ago, fo=
r 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 met=
adata/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=3Dtrue" indicating it sent the updated MSD
- IVS attaches an updated MSD in any convenient message; typically this wil=
l 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 t=
he INVITE, referenced by a Call-Info header field and can be acknowledged i=
n 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 prov=
ides a mechanism that can be easily extended in other documents (such as ca=
r-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
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


From nobody Thu Sep  1 08:51:59 2016
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8188E12D5D5 for <ecrit@ietfa.amsl.com>; Thu,  1 Sep 2016 08:51:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCTmO-Btse9O for <ecrit@ietfa.amsl.com>; Thu,  1 Sep 2016 08:51:53 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A599012D548 for <ecrit@ietf.org>; Thu,  1 Sep 2016 08:51:52 -0700 (PDT)
X-AuditID: c1b4fb2d-917ff700000019a3-f5-57c84e95d127
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by  (Symantec Mail Security) with SMTP id B9.D2.06563.59E48C75; Thu,  1 Sep 2016 17:51:50 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0301.000; Thu, 1 Sep 2016 17:51:48 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "R.Jesske@telekom.de" <R.Jesske@telekom.de>, "rg+ietf@randy.pensive.org" <rg+ietf@randy.pensive.org>, "ecrit@ietf.org" <ecrit@ietf.org>
Thread-Topic: [Ecrit] Summary of compromise proposal
Thread-Index: AQHSBFi+0aHX9V43e0SFdIcPUtJ4l6BkpjsAgAAiapA=
Date: Thu, 1 Sep 2016 15:51:48 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC7F781@ESESSMB209.ericsson.se>
References: <p06240600d3eddf1b05c2@[172.20.10.255]> <f934f494a59c452aab7cb27c92767025@HE105660.emea1.cds.t-internal.com>
In-Reply-To: <f934f494a59c452aab7cb27c92767025@HE105660.emea1.cds.t-internal.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2K7ru40vxPhBi3TdC0aFz1ltWi608Vm 8f15F6MDs8eSJT+ZPLbeeczi0fZSIYA5issmJTUnsyy1SN8ugSujd8ZCpoJdohW7j21na2Bc L9jFyMkhIWAiMfPuL0YQW0hgPaPE/MP5XYxcQPZiRon7My8BJTg42AQsJLr/aYPERQR6GSUO vXrMDNIgLGAs8W7XLRYQWwRo0NLG80wQtpXEnaVvwOIsAioSF5ZsYQexeQV8Jdpv97FCLKuS uNr8gA1kPqdAoMSS3QEgYUYBMYnvp9aAjWEWEJe49WQ+E8SdAhJL9pxnhrBFJV4+/scKYStJ NC55wgpRrydxY+oUNghbW2LZwtfMEGsFJU7OfMIygVFkFpKxs5C0zELSMgtJywJGllWMosWp xcW56UbGeqlFmcnFxfl5enmpJZsYgfFxcMtv3R2Mq187HmIU4GBU4uFNMDkRLsSaWFZcmXuI UYKDWUmE18EHKMSbklhZlVqUH19UmpNafIhRmoNFSZzX/6ViuJBAemJJanZqakFqEUyWiYNT qoFx/pzJczQyYnktToqkF9bcE5/MucjYeAGvE0uyoP4T48mnl265VGj4Yaq+7DtmliMXuPVu rtn/Lvbrn6emZ9ezHDr+WnueH/cFhYp9NeeWr+c/EF+7X9xBpjr8xNIvekfyb3z1vX/lrIW0 8RNr1QUdzwQVONJ3cb1dqbXyfF9pzebQT0+T3De8UGIpzkg01GIuKk4EAGR3pI6LAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/6FxXe8MeWQW5sTiUQb6btnEFLgA>
Subject: Re: [Ecrit] Summary of compromise proposal
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Sep 2016 15:51:57 -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:ecrit-bounces@ietf.org] On Behalf Of R.Jesske@telekom.d=
e
Sent: 01 September 2016 18:48
To: rg+ietf@randy.pensive.org; ecrit@ietf.org
Subject: Re: [Ecrit] Summary of compromise proposal

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=20

-----Urspr=FCngliche Nachricht-----
Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Randall Gellens
Gesendet: Donnerstag, 1. September 2016 15:36
An: ecrit@ietf.org
Betreff: [Ecrit] Summary of compromise proposal

Hi Everyone,

I want to summarize the compromise that was proposed a couple weeks ago, fo=
r 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 met=
adata/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=3Dtrue" indicating it sent the updated MSD
- IVS attaches an updated MSD in any convenient message; typically this wil=
l 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 t=
he INVITE, referenced by a Call-Info header field and can be acknowledged i=
n 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 prov=
ides a mechanism that can be easily extended in other documents (such as ca=
r-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
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


From nobody Thu Sep  1 09:09:11 2016
Return-Path: <R.Jesske@telekom.de>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC1212D5D5 for <ecrit@ietfa.amsl.com>; Thu,  1 Sep 2016 09:09:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.768
X-Spam-Level: 
X-Spam-Status: No, score=-4.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6oeq6E0ejEa for <ecrit@ietfa.amsl.com>; Thu,  1 Sep 2016 09:09:03 -0700 (PDT)
Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5AE12D0FC for <ecrit@ietf.org>; Thu,  1 Sep 2016 09:08:58 -0700 (PDT)
Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail91.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 01 Sep 2016 18:08:56 +0200
X-IronPort-AV: E=Sophos;i="5.30,268,1470693600"; d="scan'208";a="953038279"
Received: from he105662.emea1.cds.t-internal.com ([10.169.119.58]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES256-SHA; 01 Sep 2016 18:08:56 +0200
Received: from HE105660.EMEA1.cds.t-internal.com (10.169.119.56) by HE105662.emea1.cds.t-internal.com (10.169.119.58) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Sep 2016 18:08:55 +0200
Received: from HE105660.EMEA1.cds.t-internal.com ([fe80::c5cd:6c67:9f4d:7318]) by HE105660.emea1.cds.t-internal.com ([fe80::c5cd:6c67:9f4d:7318%26]) with mapi id 15.00.1178.000; Thu, 1 Sep 2016 18:08:55 +0200
From: <R.Jesske@telekom.de>
To: <christer.holmberg@ericsson.com>, <rg+ietf@randy.pensive.org>, <ecrit@ietf.org>
Thread-Topic: [Ecrit] Summary of compromise proposal
Thread-Index: AQHSBFi/FCptCKxyuUSXXzAMQz0RDqBkk4GAgAA0SZA=
Date: Thu, 1 Sep 2016 16:08:55 +0000
Message-ID: <cdf5f98fcdce459ebca4ad8d5cb28920@HE105660.emea1.cds.t-internal.com>
References: <p06240600d3eddf1b05c2@[172.20.10.255]> <7594FB04B1934943A5C02806D1A2204B4BC7F33C@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC7F33C@ESESSMB209.ericsson.se>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.213.93.147]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/zNfM99COVy5AlwFBeClh9JjEBpQ>
Subject: Re: [Ecrit] Summary of compromise proposal
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Sep 2016 16:09:08 -0000

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

To make my mid up I have some questions.

For me it would be very important that I have the Information as soon as po=
ssible 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 mor=
e than one MSD Block is sent?

Best Regards

Roland




-----Urspr=FCngliche Nachricht-----
Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Christer Holmberg
Gesendet: Donnerstag, 1. September 2016 16:41
An: Randall Gellens; ecrit@ietf.org
Betreff: Re: [Ecrit] Summary of compromise proposal

Hi,

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

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

While I highly appreciate Dale=B9s input on the INFO issue, it seems like w=
e won=B9t get much wider input from the SIPCORE community.

So, in order to try to move forward, I would like to suggest a compromise p=
roposal of my own. From a SIP message structure perspective it=B9s basicall=
y what Dale has suggested (and what I assumed was already stated in draft-e=
call-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 mec=
hanism for carrying the MSD in INFO. The main text does not talk about usin=
g the additional data mechanism.

Third, and this is where my comprise proposal comes it, within the info pac=
kage 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 IN=
FO.=20

Would people be ok with that?


INFO example:


Call-Info:   <cid:X>;purpose=3DemergencyCallData.eCall.MSD
Content-Type: multipart/mixed;boundary=3D"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 P=
ackage also for MSD, but we allow inclusion of the Call-Info header field i=
n the INFOs carrying the MSDs.

Regards,

Christer



-----Original Message-----
From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens
Sent: 01 September 2016 16:36
To: ecrit@ietf.org
Subject: [Ecrit] Summary of compromise proposal

Hi Everyone,

I want to summarize the compromise that was proposed a couple weeks ago, fo=
r 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 met=
adata/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=3Dtrue" indicating it sent the updated MSD
- IVS attaches an updated MSD in any convenient message; typically this wil=
l 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 t=
he INVITE, referenced by a Call-Info header field and can be acknowledged i=
n 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 prov=
ides a mechanism that can be easily extended in other documents (such as ca=
r-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
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


From nobody Thu Sep  1 09:17:51 2016
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A3512B02B for <ecrit@ietfa.amsl.com>; Thu,  1 Sep 2016 09:17:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOhm4R7PybaK for <ecrit@ietfa.amsl.com>; Thu,  1 Sep 2016 09:17:44 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91ACE12B01E for <ecrit@ietf.org>; Thu,  1 Sep 2016 09:17:44 -0700 (PDT)
X-AuditID: c1b4fb3a-0618b980000009bd-25-57c854a6bfa0
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by  (Symantec Mail Security) with SMTP id 24.20.02493.6A458C75; Thu,  1 Sep 2016 18:17:42 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0301.000; Thu, 1 Sep 2016 18:17:39 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "R.Jesske@telekom.de" <R.Jesske@telekom.de>, "rg+ietf@randy.pensive.org" <rg+ietf@randy.pensive.org>, "ecrit@ietf.org" <ecrit@ietf.org>
Thread-Topic: [Ecrit] Summary of compromise proposal
Thread-Index: AQHSBFi+0aHX9V43e0SFdIcPUtJ4l6BktHlg///3lYCAACJi8A==
Date: Thu, 1 Sep 2016 16:17:39 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC7F979@ESESSMB209.ericsson.se>
References: <p06240600d3eddf1b05c2@[172.20.10.255]> <7594FB04B1934943A5C02806D1A2204B4BC7F33C@ESESSMB209.ericsson.se> <cdf5f98fcdce459ebca4ad8d5cb28920@HE105660.emea1.cds.t-internal.com>
In-Reply-To: <cdf5f98fcdce459ebca4ad8d5cb28920@HE105660.emea1.cds.t-internal.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7se6ykBPhBrff61k0LnrKatF0p4vN 4vvzLkYHZo8lS34yeWy985jFo+2lQgBzFJdNSmpOZllqkb5dAlfGu/+nmAum61Ts23uEtYHx mHIXIyeHhICJxKOe5SxdjFwcQgLrGSVuHzkL5SxmlNj3BMTh4GATsJDo/qcNEhcR6GWUOPTq MTNIt7CAscS7XbdYQGwRoElLG88zQdhOEse7r4LFWQRUJM73bQaL8wr4Suw9tpMNYsE+RonW TafYQBKcAoESU77fARvKKCAm8f3UGrAGZgFxiVtP5jNBnCogsWTPeWYIW1Ti5eN/rBC2kkTj kiesEPV6EjemTmGDsLUlli18zQyxWFDi5MwnLBMYRWYhGTsLScssJC2zkLQsYGRZxShanFpc nJtuZKSXWpSZXFycn6eXl1qyiREYJQe3/LbawXjwueMhRgEORiUe3gSTE+FCrIllxZW5hxgl OJiVRHg/BQCFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1 MHpPav4fUlvprNdxeN2ybZm/pwn9LX7zYUPPyTPqedPNJvwO0W3XkWRJfcP3zlT9+ba52/8c DNtTEr5DpYo12tM1a/PMo2Zqh+5K/tZYZ/XP7Ime+G2j6Et/3OvXt5f77nxcss7pEOvS0l26 k6NkL57p/SoYtzzjLavk9JayiV5eT9ftWZOr80aJpTgj0VCLuag4EQA0uOOVjgIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/tHj5N6v4sUs-lq5PVI19JkKkznY>
Subject: Re: [Ecrit] Summary of compromise proposal
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Sep 2016 16:17:49 -0000

Hi,

>your proposal is straight forward that you would like to use only one tran=
sport >mechanism for MSD.=20

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 (fo=
r whatever purpose), so it would look like the INVITE mechanism.

>To make my mid up I have some questions.
>
>For me it would be very important that I have the Information as soon as p=
ossible >within the PSAP. Question is if a couple of milliseconds more unti=
l 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 devic=
es. That you need to discuss with your vendors and network designers.

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

The PSAP can request the device for a new MSD exchange. But it is not expec=
ted 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=FCngliche Nachricht-----
Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Christer Holmberg
Gesendet: Donnerstag, 1. September 2016 16:41
An: Randall Gellens; ecrit@ietf.org
Betreff: Re: [Ecrit] Summary of compromise proposal

Hi,

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

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

While I highly appreciate Dale=B9s input on the INFO issue, it seems like w=
e won=B9t get much wider input from the SIPCORE community.

So, in order to try to move forward, I would like to suggest a compromise p=
roposal of my own. From a SIP message structure perspective it=B9s basicall=
y what Dale has suggested (and what I assumed was already stated in draft-e=
call-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 mec=
hanism for carrying the MSD in INFO. The main text does not talk about usin=
g the additional data mechanism.

Third, and this is where my comprise proposal comes it, within the info pac=
kage 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 IN=
FO.=20

Would people be ok with that?


INFO example:


Call-Info:   <cid:X>;purpose=3DemergencyCallData.eCall.MSD
Content-Type: multipart/mixed;boundary=3D"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 P=
ackage also for MSD, but we allow inclusion of the Call-Info header field i=
n the INFOs carrying the MSDs.

Regards,

Christer



-----Original Message-----
From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens
Sent: 01 September 2016 16:36
To: ecrit@ietf.org
Subject: [Ecrit] Summary of compromise proposal

Hi Everyone,

I want to summarize the compromise that was proposed a couple weeks ago, fo=
r 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 met=
adata/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=3Dtrue" indicating it sent the updated MSD
- IVS attaches an updated MSD in any convenient message; typically this wil=
l 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 t=
he INVITE, referenced by a Call-Info header field and can be acknowledged i=
n 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 prov=
ides a mechanism that can be easily extended in other documents (such as ca=
r-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
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


From nobody Sat Sep  3 06:19:05 2016
Return-Path: <keith.drage@nokia.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93B812D127 for <ecrit@ietfa.amsl.com>; Sat,  3 Sep 2016 06:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level: 
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUghSopFNB5t for <ecrit@ietfa.amsl.com>; Sat,  3 Sep 2016 06:19:02 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D2F112B02A for <ecrit@ietf.org>; Sat,  3 Sep 2016 06:19:02 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 6338F78FF772F; Sat,  3 Sep 2016 12:48:45 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u83Cmlde004881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 3 Sep 2016 12:48:48 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u83Cmlcl011460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Sep 2016 14:48:47 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.50]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Sat, 3 Sep 2016 14:48:47 +0200
From: "Drage, Keith (Nokia - GB)" <keith.drage@nokia.com>
To: "R.Jesske@telekom.de" <R.Jesske@telekom.de>, "rg+ietf@randy.pensive.org" <rg+ietf@randy.pensive.org>, "ecrit@ietf.org" <ecrit@ietf.org>
Thread-Topic: [Ecrit] Summary of compromise proposal
Thread-Index: AQHSBFjIYNS4AvHvlUeHZIJI1WQo7aBkpjoAgALxV/A=
Date: Sat, 3 Sep 2016 12:48:46 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8BADF6109E@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <p06240600d3eddf1b05c2@[172.20.10.255]> <f934f494a59c452aab7cb27c92767025@HE105660.emea1.cds.t-internal.com>
In-Reply-To: <f934f494a59c452aab7cb27c92767025@HE105660.emea1.cds.t-internal.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/T6g0HLEBw8K9dYKnkGOKNXSXXDU>
Subject: Re: [Ecrit] Summary of compromise proposal
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Sep 2016 13:19:05 -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 t=
he 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:ecrit-bounces@ietf.org] On Behalf Of R.Jesske@telekom.d=
e
Sent: 01 September 2016 16:48
To: rg+ietf@randy.pensive.org; ecrit@ietf.org
Subject: Re: [Ecrit] Summary of compromise proposal

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=20

-----Urspr=FCngliche Nachricht-----
Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Randall Gellens
Gesendet: Donnerstag, 1. September 2016 15:36
An: ecrit@ietf.org
Betreff: [Ecrit] Summary of compromise proposal

Hi Everyone,

I want to summarize the compromise that was proposed a couple weeks ago, fo=
r 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 met=
adata/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=3Dtrue" indicating it sent the updated MSD
- IVS attaches an updated MSD in any convenient message; typically this wil=
l 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 t=
he INVITE, referenced by a Call-Info header field and can be acknowledged i=
n 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 prov=
ides a mechanism that can be easily extended in other documents (such as ca=
r-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
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


From nobody Thu Sep  8 03:42:55 2016
Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA0F12B0F2 for <ecrit@ietfa.amsl.com>; Thu,  8 Sep 2016 03:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.109
X-Spam-Level: 
X-Spam-Status: No, score=-4.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGguF-h1aQk2 for <ecrit@ietfa.amsl.com>; Thu,  8 Sep 2016 03:42:53 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3437612B0CF for <ecrit@ietf.org>; Thu,  8 Sep 2016 03:42:53 -0700 (PDT)
Received: from [192.168.91.132] ([80.92.121.21]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MLujU-1bgsSs1Syi-007opD; Thu, 08 Sep 2016 12:42:50 +0200
To: Randall Gellens <rg+ietf@randy.pensive.org>, ecrit@ietf.org
References: <p06240600d3eddf1b05c2@[172.20.10.255]>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Message-ID: <4e397507-b701-bb78-4d69-660286cfbd02@gmx.net>
Date: Thu, 8 Sep 2016 12:42:49 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <p06240600d3eddf1b05c2@[172.20.10.255]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:is0mGkMpnEng8AjaINyPj9LvFmTt+NsmZFMskaDwo2/GzCV+wmA sIB8dQqiahgStuwUT4ugYjbJDuCzGZbpFTXCljTqNx/8+Ztq/kikdJhc31eHexPLnGwB6g+ MZvOHn+Tc2Pu55TiGTKonqIAfZX9kp+rXjD3pQSKxf/0+05aZcgSQcOdVUi0XzoO4KeIMYj RXa4OXChanq8eqlM7COhw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:teWxxTBaO5I=:An8f6xZNRkf69O6NQUvj3h fA+m53kIqvnpavKX06geVnyaSp23nyWiVEeunX0tVdDsg5HAZUw39Xp8g1dzJSK3d4DwucbYx aNwebYd+UaDUTi7u8/8VV++NAHfEQv4ZMMf03eHFAvTJrEVfeq1br2h8bsxBA8YKeRYwDCitW qxf5NEfbUNs24DcsueRg2OMP0oz8qs+SopyWHMstbhrP/mKjOvkl2Stqjiu7F68Q/er+1yXbt PCNIcjWAn6hUGORjJPlElt0OpSBBctoeqOhCKqqtW91OlgzhYOadZmUPH9bu13cnOpo37mt19 9KBoj0JxaawhFzg9qY7yWC7A8YVUisGMJ8J2ttu3S/SeFtLkKvNOxOFwgtLIwgEe67ggGSNXR OA15D262ZEv9NGjVcmSlTPfD8kAf9pPzimTB1DUDQSzOSFjf+LsmEWvW7wderB0+T8hxPZlDp O8OaqUUszq0zd0uMV0vcEohWzSg0kX9e/05ekVO6N6gufNZnhmKmA4cy6anZrcXTUaFUMTT/x jThZWZfszTyqfXdJFCoSDZj+/uaZka+urTpBxVqN6Rw77c3eIGjm5apxMoy6Rh5nBMVUPOKzb B6nd5Ccnl5F7i9hDtyr4vwuTzwr8uFnZqOIjOeVlqKE1wZx0KjN5f0ugR9DvG/l1lwmxNGnjG aJZ1CwkHu3OzR2qm+xU5lhXertA8J7caosznazgTofgNObcsQdwkQ0Sx3Hdh/gAYeYr6fv7AJ VHQqt6O7RKXy4kOCcL/2hhPovdRCTn+To/rDPO68yrDpP9w6veL9p40uIQq6nLhznoUa+fSM+ b/cBpr7
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/mkrSgtk_zgwAJU9gsq30vKMAKgQ>
Subject: Re: [Ecrit] Summary of compromise proposal
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2016 10:42:55 -0000

Hi Randy,

I am OK with this compromise.

Ciao
Hannes

On 09/01/2016 03:35 PM, Randall Gellens wrote:
> 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).
>


From nobody Thu Sep  8 03:48:11 2016
Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE62C12B0AF for <ecrit@ietfa.amsl.com>; Thu,  8 Sep 2016 03:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.109
X-Spam-Level: 
X-Spam-Status: No, score=-4.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1ovpmSPTbgz for <ecrit@ietfa.amsl.com>; Thu,  8 Sep 2016 03:48:07 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E65312B15C for <ecrit@ietf.org>; Thu,  8 Sep 2016 03:48:07 -0700 (PDT)
Received: from [192.168.91.132] ([80.92.121.21]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MZwYd-1bTry90mEh-00LqtH; Thu, 08 Sep 2016 12:48:02 +0200
To: Alissa Cooper <alissa@cooperw.in>, Emergency Context Resolution with Internet Technologies Discussion List <ecrit@ietf.org>
References: <BBB5C38C-27FF-4B0D-935B-06C91CE9FD27@cooperw.in>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Message-ID: <8e272650-3280-3589-fd0f-fcd23344eb00@gmx.net>
Date: Thu, 8 Sep 2016 12:48:01 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <BBB5C38C-27FF-4B0D-935B-06C91CE9FD27@cooperw.in>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:Uyaud5UZ/WAoc68L0kZc9F3xM1fApWJK+emelWAUgCaYLaacXsF MlRze70aK8mkp31qR9VlNIeSoUEUYRqdhzyueKPI7EiwPLE/otwHvjcQhHYj0LzP6BWdPFi QUj2vpi2a4SPaKb8gyPHvq+ifdDoE/F4QpgmJl0a19k3EhT/eBRvEL8xMKUa6ALN1tvr5Gk qaJVAszR+b9SJTb2gzrYA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:zQTQswHEFp4=:/zvUVXFqQOqUU4kCiZvUwt iwZ/iCZb96/rRK3fL5sIDD6j5b+YWCNnAg6KXfSx3HdXHZ2GZAVEpiH+xCysapKIjjOScrJRX UpafaNz+HWG7/e2cKM3RrGXrkamuPlv5ShzDU8xVG/Z/HHbu8ith9uRE2zOCCYKqIP5sAlAcA EUw/iBQnMaj9d1ujMVJboaReWGAo0Pefvx1a7K7DgtU26RvId1SSRPCja52dQHTRGXT3zEzQJ aRwSADndoFxl+lsks83n9UZIMWzEZ859dvX/VgCT+/0DU75B0EkHVXgxWJghv2n0Y0Am3rWqg Hu1Cr4AljRGp9qVDnbMxnHRDaBPihRg4i1gDtoqQqj09cPIQTptlfHxpLmw6IxOc5SgphEPy7 2qPMRTWDG/KBmfAYyL0vObrdFiszrNOCdm6DZFTxosguM9q6tmtAJtul6cyVsrXZ+2bdrLWrG DjqMaQ8s8RLQqlg2xPS/x5qYQ2HKYTQZTZ/rD8su9cthKQTIyqB2VFEDcjzdGrdjmtey75IsX QxSuENqRAKxOCQotedK9h1B+nycMPfgXLYggKdml0sFNZoMLqACcQ5luFWeLLJcxdf4MhkUo1 zVuzpRIniaZjtZEsfSX4mGde/GlIjuwxQoxPBRcWbw2AgcWdcFQeN2QiErUMIk3oV1uKrWUVr snpLxy8rVdctiJK/r7bG0GqN7pzJGfc/rawnt0mZ8eiTiYaldcOF3We/hUTEV0Tnpq9tcYoQB Ssu/C0VO7VfgNNm9xXcy/ZC8w7Sgmtnng7J6SfyqnBlGPc8UzosvDHyYHa4/u6/BjBbTNIEoU /KvoLUb
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/kXIF83qErpY9-lJOOF_J5O3XHQ8>
Subject: Re: [Ecrit] Chair update
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2016 10:48:09 -0000

Marc has co-chaired the ECRIT since the formation in March 2005. 
Furthermore, he was active in putting the SDO emergency services 
workshop series together, which helped us to reach out to so many other 
SDOs, researchers, companies, regulators, and advocacy groups.

The group has developed many key emergency services standards used by 
other organizations world-wide.

Thank you, Marc, for all the work you did in the ECRIT working group.

Ciao
Hannes


On 08/30/2016 05:36 PM, Alissa Cooper wrote:
> Hi all,
>
> Marc Linsner has stepped down as ECRIT co-chair. Huge thanks to Marc for his many years of leadership in this WG.
>
> Allison Mankin has agreed to join Roger as ECRIT co-chair. Welcome, Allison!
>
> Alissa
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>


From nobody Thu Sep  8 03:50:32 2016
Return-Path: <ivo.sedlacek@ericsson.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A76412B2D5 for <ecrit@ietfa.amsl.com>; Thu,  8 Sep 2016 03:50:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNbIw_RqqO0K for <ecrit@ietfa.amsl.com>; Thu,  8 Sep 2016 03:50:27 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15D0012B181 for <ecrit@ietf.org>; Thu,  8 Sep 2016 03:50:18 -0700 (PDT)
X-AuditID: c1b4fb3a-0618b980000009bd-e3-57d14269133c
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by  (Symantec Mail Security) with SMTP id 62.4A.02493.96241D75; Thu,  8 Sep 2016 12:50:17 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.41]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0301.000; Thu, 8 Sep 2016 12:50:15 +0200
From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, Randall Gellens <rg+ietf@randy.pensive.org>, "ecrit@ietf.org" <ecrit@ietf.org>
Thread-Topic: [Ecrit] Summary of compromise proposal
Thread-Index: AQHSBFi+QEnlHds5rEmuuguqy6WeH6BvUUOAgAAjC8A=
Date: Thu, 8 Sep 2016 10:50:15 +0000
Message-ID: <39B5E4D390E9BD4890E2B31079006101165286EA@ESESSMB301.ericsson.se>
References: <p06240600d3eddf1b05c2@[172.20.10.255]> <4e397507-b701-bb78-4d69-660286cfbd02@gmx.net>
In-Reply-To: <4e397507-b701-bb78-4d69-660286cfbd02@gmx.net>
Accept-Language: en-US, cs-CZ
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2K7rm6m08Vwg6/n5C0aFz1ltVi68x6r xffnXYwOzB6LN+1n81iy5CeTx9Y7j1kCmKO4bFJSczLLUov07RK4Mu7+2MJSsFGgov3FA+YG xhW8XYycHBICJhLnP9xn62Lk4hASWM8oMXHdDShnEaPE53lzWUCq2AT0JCZuOcIKkhARaGaU 6Fpwiw0kISxgLPFu1y2wIhGgUUsbzzNB2FYS188sYe9i5OBgEVCRmPwsDSTMK+Ar0Xb7NiuI LSSQInFu1i+wck4Ba4m9mzqZQWxGAVmJq396GUFsZgFxiVtP5jNBXCogsWTPeWYIW1Ti5eN/ rBC2osTHV/ug6nUkFuz+xAZha0ssW/iaGWKvoMTJmU9YJjCKzEIydhaSlllIWmYhaVnAyLKK UbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzBKDm75bbWD8eBzx0OMAhyMSjy8CbIXwoVYE8uK K3MPMUpwMCuJ8CY5XgwX4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuv/UjFcSCA9sSQ1OzW1ILUI JsvEwSnVwJh0bJ7/pceaBol99Xpxu9Yusbz5Q0f0a9rUGW2BWzY7zL3X/+L6pxktIa4RyTq7 r7CUFxp2PNgh3O62izvnnG7tzTsrZ7NKTYvusJOu7FdIXJL9L/u0457FRfsmTd7U7mGpsyyJ 406UUkro3dS1LkbhzWdOzLnEb795jtxz3c3LXcrsP/sflFViKc5INNRiLipOBAAkKlafjgIA AA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/eg3DZjxCqPhSUAmelO0Vfs8WIVE>
Subject: Re: [Ecrit] Summary of compromise proposal
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2016 10:50:30 -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:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, September 08, 2016 12:43 PM
To: Randall Gellens; ecrit@ietf.org
Subject: Re: [Ecrit] Summary of compromise proposal

Hi Randy,

I am OK with this compromise.

Ciao
Hannes

On 09/01/2016 03:35 PM, Randall Gellens wrote:
> Hi Everyone,
>
> I want to summarize the compromise that was proposed a couple weeks=20
> 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=20
> using Call-Info to refer to it
> - PSAP requests an updated MSD mid-call by sending an INFO containing=20
> a metadata/control object requesting an MSD, per the INFO package,=20
> with
> "Content-Disposition: info-package", and no Call-Info header field
> - IVS sends an INFO with a metadata/control object containing an ACK=20
> with "success=3Dtrue" indicating it sent the updated MSD
> - IVS attaches an updated MSD in any convenient message; typically=20
> this will be the INFO with the ACK
>
>
> This means that the INFO package defines a clean request/response=20
> protocol, while the MSD remains Additional Data per RFC 7852.
>
> For the initial MSD (unchanged by the compromise), the MSD is included=20
> in the INVITE, referenced by a Call-Info header field and can be=20
> acknowledged in a final response (e.g. 200, 4xx, 6xx) using a metadata=20
> object referenced by a Call-Info header field.
>
> The authors believe this compromise addresses the concerns raised, and=20
> provides a mechanism that can be easily extended in other documents=20
> (such as car-crash or future documents).
>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


From nobody Thu Sep  8 04:29:30 2016
Return-Path: <md3135@att.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC6F12B163 for <ecrit@ietfa.amsl.com>; Thu,  8 Sep 2016 04:29:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VskWAimhefIH for <ecrit@ietfa.amsl.com>; Thu,  8 Sep 2016 04:29:28 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6A012B0E1 for <ecrit@ietf.org>; Thu,  8 Sep 2016 04:29:28 -0700 (PDT)
Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u88BOliI029326; Thu, 8 Sep 2016 07:29:23 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 25b6e6w7ey-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 08 Sep 2016 07:29:22 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u88BTMZg003895; Thu, 8 Sep 2016 07:29:22 -0400
Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u88BTA2f003745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Sep 2016 07:29:17 -0400
Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 8 Sep 2016 11:29:05 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.137]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0301.000; Thu, 8 Sep 2016 07:29:05 -0400
From: "DOLLY, MARTIN C" <md3135@att.com>
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, Randall Gellens <rg+ietf@randy.pensive.org>, "ecrit@ietf.org" <ecrit@ietf.org>
Thread-Topic: [Ecrit] Summary of compromise proposal
Thread-Index: AQHSCb3HxCIDGmvCs0yXMbHEwlq2lqBvrSKA///Hq3A=
Date: Thu, 8 Sep 2016 11:29:03 +0000
Message-ID: <E42CCDDA6722744CB241677169E836564A9D14A4@MISOUT7MSGUSRDB.ITServices.sbc.com>
References: <p06240600d3eddf1b05c2@[172.20.10.255]> <4e397507-b701-bb78-4d69-660286cfbd02@gmx.net> <39B5E4D390E9BD4890E2B31079006101165286EA@ESESSMB301.ericsson.se>
In-Reply-To: <39B5E4D390E9BD4890E2B31079006101165286EA@ESESSMB301.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.10.165.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-08_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1609080167
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/5_KyOZEzUcY87RZWzvhHCfn96Lk>
Subject: Re: [Ecrit] Summary of compromise proposal
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2016 11:29:30 -0000

I also support Christer's compromise

-----Original Message-----
From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek
Sent: Thursday, September 08, 2016 6:50 AM
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>; Randall Gellens <rg+ietf=
@randy.pensive.org>; ecrit@ietf.org
Subject: Re: [Ecrit] Summary of compromise proposal

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:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, September 08, 2016 12:43 PM
To: Randall Gellens; ecrit@ietf.org
Subject: Re: [Ecrit] Summary of compromise proposal

Hi Randy,

I am OK with this compromise.

Ciao
Hannes

On 09/01/2016 03:35 PM, Randall Gellens wrote:
> Hi Everyone,
>
> I want to summarize the compromise that was proposed a couple weeks=20
> 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=20
> using Call-Info to refer to it
> - PSAP requests an updated MSD mid-call by sending an INFO containing=20
> a metadata/control object requesting an MSD, per the INFO package,=20
> with
> "Content-Disposition: info-package", and no Call-Info header field
> - IVS sends an INFO with a metadata/control object containing an ACK=20
> with "success=3Dtrue" indicating it sent the updated MSD
> - IVS attaches an updated MSD in any convenient message; typically=20
> this will be the INFO with the ACK
>
>
> This means that the INFO package defines a clean request/response=20
> protocol, while the MSD remains Additional Data per RFC 7852.
>
> For the initial MSD (unchanged by the compromise), the MSD is included=20
> in the INVITE, referenced by a Call-Info header field and can be=20
> acknowledged in a final response (e.g. 200, 4xx, 6xx) using a metadata=20
> object referenced by a Call-Info header field.
>
> The authors believe this compromise addresses the concerns raised, and=20
> provides a mechanism that can be easily extended in other documents=20
> (such as car-crash or future documents).
>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


From nobody Thu Sep  8 05:37:43 2016
Return-Path: <R.Jesske@telekom.de>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE4E12B5D1 for <ecrit@ietfa.amsl.com>; Thu,  8 Sep 2016 05:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.728
X-Spam-Level: 
X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEvBoZzF2Wms for <ecrit@ietfa.amsl.com>; Thu,  8 Sep 2016 05:37:37 -0700 (PDT)
Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E8312B408 for <ecrit@ietf.org>; Thu,  8 Sep 2016 05:20:10 -0700 (PDT)
Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail41.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 08 Sep 2016 14:20:08 +0200
X-IronPort-AV: E=Sophos;i="5.30,300,1470693600"; d="scan'208";a="1139651778"
Received: from he105828.emea1.cds.t-internal.com ([10.169.119.31]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES256-SHA; 08 Sep 2016 14:20:04 +0200
Received: from HE105828.EMEA1.cds.t-internal.com (10.169.119.31) by HE105828.emea1.cds.t-internal.com (10.169.119.31) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 8 Sep 2016 14:20:04 +0200
Received: from HE105828.EMEA1.cds.t-internal.com ([fe80::753e:c05:6c77:b585]) by HE105828.emea1.cds.t-internal.com ([fe80::753e:c05:6c77:b585%26]) with mapi id 15.00.1210.000; Thu, 8 Sep 2016 14:20:04 +0200
From: <R.Jesske@telekom.de>
To: <ivo.sedlacek@ericsson.com>, <hannes.tschofenig@gmx.net>, <rg+ietf@randy.pensive.org>, <ecrit@ietf.org>
Thread-Topic: [Ecrit] Summary of compromise proposal
Thread-Index: AQHSBFi/FCptCKxyuUSXXzAMQz0RDqBvUUOAgAACFICAADazAA==
Date: Thu, 8 Sep 2016 12:20:04 +0000
Message-ID: <761beaeff89d4542b04db4555237fc06@HE105828.emea1.cds.t-internal.com>
References: <p06240600d3eddf1b05c2@[172.20.10.255]> <4e397507-b701-bb78-4d69-660286cfbd02@gmx.net> <39B5E4D390E9BD4890E2B31079006101165286EA@ESESSMB301.ericsson.se>
In-Reply-To: <39B5E4D390E9BD4890E2B31079006101165286EA@ESESSMB301.ericsson.se>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.157.244.188]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/26k3U86LEWes7Vj_iBkxIa3Ur0c>
Subject: Re: [Ecrit] Summary of compromise proposal
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2016 12:37:42 -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 State=
ment.

Or what do you mean?
=20
Best Regards

Roland

-----Urspr=FCngliche Nachricht-----
Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Ivo Sedlacek
Gesendet: Donnerstag, 8. September 2016 12:50
An: Hannes Tschofenig; Randall Gellens; ecrit@ietf.org
Betreff: Re: [Ecrit] Summary of compromise proposal

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:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, September 08, 2016 12:43 PM
To: Randall Gellens; ecrit@ietf.org
Subject: Re: [Ecrit] Summary of compromise proposal

Hi Randy,

I am OK with this compromise.

Ciao
Hannes

On 09/01/2016 03:35 PM, Randall Gellens wrote:
> Hi Everyone,
>
> I want to summarize the compromise that was proposed a couple weeks=20
> 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=20
> using Call-Info to refer to it
> - PSAP requests an updated MSD mid-call by sending an INFO containing=20
> a metadata/control object requesting an MSD, per the INFO package,=20
> with
> "Content-Disposition: info-package", and no Call-Info header field
> - IVS sends an INFO with a metadata/control object containing an ACK=20
> with "success=3Dtrue" indicating it sent the updated MSD
> - IVS attaches an updated MSD in any convenient message; typically=20
> this will be the INFO with the ACK
>
>
> This means that the INFO package defines a clean request/response=20
> protocol, while the MSD remains Additional Data per RFC 7852.
>
> For the initial MSD (unchanged by the compromise), the MSD is included=20
> in the INVITE, referenced by a Call-Info header field and can be=20
> acknowledged in a final response (e.g. 200, 4xx, 6xx) using a metadata=20
> object referenced by a Call-Info header field.
>
> The authors believe this compromise addresses the concerns raised, and=20
> provides a mechanism that can be easily extended in other documents=20
> (such as car-crash or future documents).
>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


From nobody Thu Sep  8 05:52:28 2016
Return-Path: <ivo.sedlacek@ericsson.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499D912B169 for <ecrit@ietfa.amsl.com>; Thu,  8 Sep 2016 05:52:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfZaFFtM6bGZ for <ecrit@ietfa.amsl.com>; Thu,  8 Sep 2016 05:52:05 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0679F12B3C4 for <ecrit@ietf.org>; Thu,  8 Sep 2016 05:29:50 -0700 (PDT)
X-AuditID: c1b4fb30-ea88e980000009f9-a0-57d159bd083f
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by  (Symantec Mail Security) with SMTP id 55.06.02553.DB951D75; Thu,  8 Sep 2016 14:29:49 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.41]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0301.000; Thu, 8 Sep 2016 14:29:44 +0200
From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
To: "R.Jesske@telekom.de" <R.Jesske@telekom.de>, "hannes.tschofenig@gmx.net" <hannes.tschofenig@gmx.net>, "rg+ietf@randy.pensive.org" <rg+ietf@randy.pensive.org>, "ecrit@ietf.org" <ecrit@ietf.org>
Thread-Topic: [Ecrit] Summary of compromise proposal
Thread-Index: AQHSBFi+QEnlHds5rEmuuguqy6WeH6BvUUOAgAAjC8D///ghAIAAIpUw
Date: Thu, 8 Sep 2016 12:29:44 +0000
Message-ID: <39B5E4D390E9BD4890E2B3107900610116528AB3@ESESSMB301.ericsson.se>
References: <p06240600d3eddf1b05c2@[172.20.10.255]> <4e397507-b701-bb78-4d69-660286cfbd02@gmx.net> <39B5E4D390E9BD4890E2B31079006101165286EA@ESESSMB301.ericsson.se> <761beaeff89d4542b04db4555237fc06@HE105828.emea1.cds.t-internal.com>
In-Reply-To: <761beaeff89d4542b04db4555237fc06@HE105828.emea1.cds.t-internal.com>
Accept-Language: en-US, cs-CZ
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbHdRndv5MVwgyfrZSwaFz1ltVi68x6r RdOdLjaL78+7GB1YPBZv2s/msWTJTyaPrXces3i0vVQIYInisklJzcksSy3St0vgypjx8zx7 wXWpigtLr7M0MN4R7WLk5JAQMJHYc+sgUxcjF4eQwHpGid/79rJAOIsYJbb0nGUDqWIT0JOY uOUIK0hCROAEo8Se5l1gCWEBY4l3u26xgNgiQKOWNp5ngrDdJI5dm8EOYrMIqEhM6TzOCmLz CvhKbD4xkxliw3tGiZ/7Z4A1cAoESnTN28wIYjMKyEpc/dMLZjMLiEvcejKfCeJWAYkle84z Q9iiEi8f/2OFsBUlPr7aB1WvJ/Hs1CwWCFtbYtnC18wQiwUlTs58wjKBUWQWkrGzkLTMQtIy C0nLAkaWVYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiBsXNwy2+DHYwvnzseYhTgYFTi4U2Q vRAuxJpYVlyZe4hRgoNZSYS3NOJiuBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe/5eK4UIC6Ykl qdmpqQWpRTBZJg5OqQbGSVr71okGu/xZ4TE56s3MU3f4c+bqP9ZeN5c32upD8j+jW9Kq7u84 J1TUrLm25l2hXUxtwaKHC1ZKHrBVeLtwqQev+mHfC4HTRP73dk+OTD5ooyLXtH6PO2fvm/s1 z2zjjAMWtE/12Hbu0JIpGZNu1qk5V842WCVczv9L7kB3rlFOrJzCtEcWSizFGYmGWsxFxYkA 9tstnJkCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/1hX87wqxGn251F9gL0tUIVqQK1o>
Subject: Re: [Ecrit] Summary of compromise proposal
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2016 12:52:25 -0000

Let me be clearer:

	I am not OK with Randal's compromise solution.

	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 inf=
o-package.

	I support Christer's compromise solution.

Kind regards

ivo

-----Original Message-----
From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20
Sent: Thursday, September 08, 2016 2:20 PM
To: Ivo Sedlacek; hannes.tschofenig@gmx.net; rg+ietf@randy.pensive.org; ecr=
it@ietf.org
Subject: AW: [Ecrit] Summary of compromise proposal

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 State=
ment.

Or what do you mean?
=20
Best Regards

Roland

-----Urspr=FCngliche Nachricht-----
Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Ivo Sedlacek
Gesendet: Donnerstag, 8. September 2016 12:50
An: Hannes Tschofenig; Randall Gellens; ecrit@ietf.org
Betreff: Re: [Ecrit] Summary of compromise proposal

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:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, September 08, 2016 12:43 PM
To: Randall Gellens; ecrit@ietf.org
Subject: Re: [Ecrit] Summary of compromise proposal

Hi Randy,

I am OK with this compromise.

Ciao
Hannes

On 09/01/2016 03:35 PM, Randall Gellens wrote:
> Hi Everyone,
>
> I want to summarize the compromise that was proposed a couple weeks=20
> 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=20
> using Call-Info to refer to it
> - PSAP requests an updated MSD mid-call by sending an INFO containing=20
> a metadata/control object requesting an MSD, per the INFO package,=20
> with
> "Content-Disposition: info-package", and no Call-Info header field
> - IVS sends an INFO with a metadata/control object containing an ACK=20
> with "success=3Dtrue" indicating it sent the updated MSD
> - IVS attaches an updated MSD in any convenient message; typically=20
> this will be the INFO with the ACK
>
>
> This means that the INFO package defines a clean request/response=20
> protocol, while the MSD remains Additional Data per RFC 7852.
>
> For the initial MSD (unchanged by the compromise), the MSD is included=20
> in the INVITE, referenced by a Call-Info header field and can be=20
> acknowledged in a final response (e.g. 200, 4xx, 6xx) using a metadata=20
> object referenced by a Call-Info header field.
>
> The authors believe this compromise addresses the concerns raised, and=20
> provides a mechanism that can be easily extended in other documents=20
> (such as car-crash or future documents).
>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


From nobody Thu Sep  8 06:23:07 2016
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10EE12B441 for <ecrit@ietfa.amsl.com>; Thu,  8 Sep 2016 06:23:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqRoxnDLOtk4 for <ecrit@ietfa.amsl.com>; Thu,  8 Sep 2016 06:22:58 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1536012B458 for <ecrit@ietf.org>; Thu,  8 Sep 2016 06:00:20 -0700 (PDT)
X-AuditID: c1b4fb2d-cf87d980000019a3-9a-57d160e3c965
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by  (Symantec Mail Security) with SMTP id C5.ED.06563.3E061D75; Thu,  8 Sep 2016 15:00:19 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0301.000; Thu, 8 Sep 2016 15:00:15 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>, "R.Jesske@telekom.de" <R.Jesske@telekom.de>, "hannes.tschofenig@gmx.net" <hannes.tschofenig@gmx.net>, "rg+ietf@randy.pensive.org" <rg+ietf@randy.pensive.org>, "ecrit@ietf.org" <ecrit@ietf.org>
Thread-Topic: [Ecrit] Summary of compromise proposal
Thread-Index: AQHSBFi+0aHX9V43e0SFdIcPUtJ4l6BvUUOAgAACFICAABkYAIAAArMAgAA8OoA=
Date: Thu, 8 Sep 2016 13:00:14 +0000
Message-ID: <D3F73C77.EDDE%christer.holmberg@ericsson.com>
References: <p06240600d3eddf1b05c2@[172.20.10.255]> <4e397507-b701-bb78-4d69-660286cfbd02@gmx.net> <39B5E4D390E9BD4890E2B31079006101165286EA@ESESSMB301.ericsson.se> <761beaeff89d4542b04db4555237fc06@HE105828.emea1.cds.t-internal.com> <39B5E4D390E9BD4890E2B3107900610116528AB3@ESESSMB301.ericsson.se>
In-Reply-To: <39B5E4D390E9BD4890E2B3107900610116528AB3@ESESSMB301.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.5.160527
x-originating-ip: [153.88.183.147]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <9FF14E4E91FFC247AB22ECA51B952BEB@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7qO7jhIvhBn9OyFg0LnrKarF05z1W i6Y7XWwW3593MTqweCzetJ/NY8mSn0weW+88ZvFoe6kQwBLFZZOSmpNZllqkb5fAlfHlwWr2 gjlyFX+WdrA1MD6S6GLk5JAQMJFY2fKbpYuRi0NIYD2jxKc5LcwQzmJGiQl/l7N3MXJwsAlY SHT/0waJiwh8YZS4dmE3E0i3sICxxPa/IN2cQAkTiaWN55kgbD+JOU1T2EFsFgEViab5jxlB bF4BK4m/v+azQyzYzCTx5GwfE8gCTqCGmzuFQWoYBcQkvp9aAzaHWUBc4taT+UwQlwpILNlz nhnCFpV4+fgfK4gtKqAn8f3rbGaQMRICShLTtqZBtOpJ3Jg6hQ3CtpaY9m8mO4StLbFs4Wtm iHMEJU7OfMIygVFsFpJts5C0z0LSPgtJ+ywk7QsYWVcxihanFhfnphsZ66UWZSYXF+fn6eWl lmxiBEbfwS2/dXcwrn7teIhRgINRiYc3QfZCuBBrYllxZe4hRgkOZiUR3rvxF8OFeFMSK6tS i/Lji0pzUosPMUpzsCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1MM7VO1Wb78LzxPP46eK9 a6ae5uy5ee75gTIn56sx8p1sJ7+xLDoXej7stXXo32Ll35oavw792mG27bhKULv/qZzEoLec ly9Wx535sv3EDVU/hVu+eYW/7z2MkkhdqiiTdK/95N99O9LPfXQpyd2z6kjxFW1RjjXGa9nP lsoJNX785MqbfeBU9EklluKMREMt5qLiRAAocbCpugIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/vXP68BnJA9LfZFk70jIIUKR93vI>
Subject: Re: [Ecrit] Summary of compromise proposal
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2016 13:23:05 -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"
<ecrit-bounces@ietf.org on behalf of ivo.sedlacek@ericsson.com> wrote:

>Let me be clearer:
>
>	I am not OK with Randal's compromise solution.
>
>	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.
>
>	I support Christer's compromise solution.
>
>Kind regards
>
>ivo
>
>-----Original Message-----
>From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]
>Sent: Thursday, September 08, 2016 2:20 PM
>To: Ivo Sedlacek; hannes.tschofenig@gmx.net; rg+ietf@randy.pensive.org;
>ecrit@ietf.org
>Subject: AW: [Ecrit] Summary of compromise proposal
>
>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?
>=20
>Best Regards
>
>Roland
>
>-----Urspr=FCngliche Nachricht-----
>Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Ivo Sedlacek
>Gesendet: Donnerstag, 8. September 2016 12:50
>An: Hannes Tschofenig; Randall Gellens; ecrit@ietf.org
>Betreff: Re: [Ecrit] Summary of compromise proposal
>
>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:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig
>Sent: Thursday, September 08, 2016 12:43 PM
>To: Randall Gellens; ecrit@ietf.org
>Subject: Re: [Ecrit] Summary of compromise proposal
>
>Hi Randy,
>
>I am OK with this compromise.
>
>Ciao
>Hannes
>
>On 09/01/2016 03:35 PM, Randall Gellens wrote:
>> 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=3Dtrue" 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).
>>
>
>_______________________________________________
>Ecrit mailing list
>Ecrit@ietf.org
>https://www.ietf.org/mailman/listinfo/ecrit
>
>_______________________________________________
>Ecrit mailing list
>Ecrit@ietf.org
>https://www.ietf.org/mailman/listinfo/ecrit
>
>_______________________________________________
>Ecrit mailing list
>Ecrit@ietf.org
>https://www.ietf.org/mailman/listinfo/ecrit


From nobody Thu Sep  8 07:08:29 2016
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076C512B161 for <ecrit@ietfa.amsl.com>; Thu,  8 Sep 2016 07:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level: 
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YnNy4MRNxst for <ecrit@ietfa.amsl.com>; Thu,  8 Sep 2016 07:08:22 -0700 (PDT)
Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3844A12B145 for <ecrit@ietf.org>; Thu,  8 Sep 2016 07:08:19 -0700 (PDT)
Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-01v.sys.comcast.net with SMTP id hzxSbnzSSTaLwi002bjx27; Thu, 08 Sep 2016 14:08:18 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-20v.sys.comcast.net with SMTP id i001bbNovtzqti002bn66B; Thu, 08 Sep 2016 14:08:18 +0000
To: ecrit@ietf.org
References: <p06240600d3eddf1b05c2@[172.20.10.255]> <4e397507-b701-bb78-4d69-660286cfbd02@gmx.net> <39B5E4D390E9BD4890E2B31079006101165286EA@ESESSMB301.ericsson.se>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <a130a02e-8a4f-4ae8-7e6b-4688ef7223bc@alum.mit.edu>
Date: Thu, 8 Sep 2016 10:08:16 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <39B5E4D390E9BD4890E2B31079006101165286EA@ESESSMB301.ericsson.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfDJ/zUx3rOmMZUycmna1o8j9TaVZmmw2V0iUxkjKDm2Zq9/3HWrPr8rx1oojzJ3XcEz+d/p2tBjzNH8YYSei7McgmpnPGx0QXNtyvThbm9cfcnJO9duU Abeiv+yZor36H6sNJCo89nf0CdpTqHtZT7K8eWGLMKqdBgQp+hS/BH7UobbF1WTHvYeK8Ur43IyHsA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/Ji_Kh--Xp5NOsaK_JLp3h-E9Mrk>
Subject: Re: [Ecrit] Summary of compromise proposal
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2016 14:08:28 -0000

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

On 9/8/16 6:50 AM, Ivo Sedlacek wrote:
> 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:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Thursday, September 08, 2016 12:43 PM
> To: Randall Gellens; ecrit@ietf.org
> Subject: Re: [Ecrit] Summary of compromise proposal
>
> Hi Randy,
>
> I am OK with this compromise.
>
> Ciao
> Hannes
>
> On 09/01/2016 03:35 PM, Randall Gellens wrote:
>> 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).
>>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>


From nobody Thu Sep  8 11:13:21 2016
Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4122312B20C for <ecrit@ietfa.amsl.com>; Thu,  8 Sep 2016 11:13:20 -0700 (PDT)
X-Quarantine-ID: <oeJc-g_vrVJ7>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -3.408
X-Spam-Level: 
X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeJc-g_vrVJ7 for <ecrit@ietfa.amsl.com>; Thu,  8 Sep 2016 11:13:19 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5142A12B206 for <ecrit@ietf.org>; Thu,  8 Sep 2016 11:13:19 -0700 (PDT)
Received: from [10.0.210.183] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 8 Sep 2016 11:13:18 -0700
Mime-Version: 1.0
Message-Id: <p06240601d3f753a32021@[10.0.210.183]>
In-Reply-To: <39B5E4D390E9BD4890E2B31079006101165286EA@ESESSMB301.ericsson.se>
References: <p06240600d3eddf1b05c2@[172.20.10.255]> <4e397507-b701-bb78-4d69-660286cfbd02@gmx.net> <39B5E4D390E9BD4890E2B31079006101165286EA@ESESSMB301.ericsson.se>
X-Mailer: Eudora for Mac OS X
Date: Thu, 8 Sep 2016 11:13:14 -0700
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, "ecrit@ietf.org" <ecrit@ietf.org>, Brian Rosen <Brian.Rosen@neustar.biz>, Martin Dolly <md3135@att.com>, "Dale R. Worley" <worley@ariadne.com>, R.Jesske@telekom.de
From: Randall Gellens <rg+ietf@randy.pensive.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/a9f9ffC4XGj8PqnNiX1ZoQN7aMM>
Subject: Re: [Ecrit] Summary of compromise proposal
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2016 18:13:20 -0000

At 10:50 AM +0000 9/8/16, Ivo Sedlacek wrote:

>  I support Christer's compromise solution.

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.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- 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)


From nobody Wed Sep 21 16:16:54 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: ecrit@ietf.org
Delivered-To: ecrit@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 432E112BE22; Wed, 21 Sep 2016 16:16:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.33.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147449980521.14533.4540811913038730239.idtracker@ietfa.amsl.com>
Date: Wed, 21 Sep 2016 16:16:45 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/Z15zyACEWLPXgfdRTNELd_luegM>
Cc: ecrit@ietf.org
Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-12.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Sep 2016 23:16:45 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Emergency Context Resolution with Internet Technologies of the IETF.

        Title           : Next-Generation Pan-European eCall
        Authors         : Randall Gellens
                          Hannes Tschofenig
	Filename        : draft-ietf-ecrit-ecall-12.txt
	Pages           : 43
	Date            : 2016-09-21

Abstract:
   This document describes how to use IP-based emergency services
   mechanisms to support the next generation of the Pan European in-
   vehicle emergency call service defined under the eSafety initiative
   of the European Commission (generally referred to as "eCall"). eCall
   is a standardized and mandated system for a special form of emergency
   calls placed by vehicles, providing real-time communications and an
   integrated set of related data.

   This document also registers MIME Content Types and an Emergency Call
   Additional Data Blocks for the eCall vehicle data and metadata/
   control data.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ecrit-ecall-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Sep 21 16:17:43 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: ecrit@ietf.org
Delivered-To: ecrit@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E015512D1BD; Wed, 21 Sep 2016 16:17:26 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.33.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147449984691.14574.14733945301450103878.idtracker@ietfa.amsl.com>
Date: Wed, 21 Sep 2016 16:17:26 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/Lqk_e_YDJseeek0ctQ-yEuM6Dl8>
Cc: ecrit@ietf.org
Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-10.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Sep 2016 23:17:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Emergency Context Resolution with Internet Technologies of the IETF.

        Title           : Next-Generation Vehicle-Initiated Emergency Calls
        Authors         : Randall Gellens
                          Brian Rosen
                          Hannes Tschofenig
	Filename        : draft-ietf-ecrit-car-crash-10.txt
	Pages           : 42
	Date            : 2016-09-21

Abstract:
   This document describes how to use IP-based emergency services
   mechanisms to support the next generation of emergency calls placed
   by vehicles (automatically in the event of a crash or serious
   incident, or manually invoked by a vehicle occupant) and conveying
   vehicle, sensor, and location data related to the crash or incident.
   Such calls are often referred to as "Automatic Crash Notification"
   (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the
   case of manual trigger.  The "Advanced" qualifier refers to the
   ability to carry a richer set of data.

   This document also registers a MIME Content Type and Emergency Call
   Additional Data Block for the vehicle, sensor, and location data
   (often referred to as "crash data" even though there is not
   necessarily a crash).  An external specification for the data format,
   contents, and structure are referenced in this document.

   This document reuses the technical aspects of next-generation pan-
   European eCall (a mandated and standardized system for emergency
   calls by in-vehicle systems within Europe and other regions).
   However, this document specifies a different set of vehicle (crash)
   data, specifically, the Vehicle Emergency Data Set (VEDS) rather than
   the eCall Minimum Set of Data (MSD).  This document is an extension
   of the eCall document, with the primary differences being that this
   document makes the MSD data set optional and VEDS mandatory, and adds
   attribute values to the eCall metadata/control object to permit
   greater functionality.  This document registers a new INFO package
   (identical to that registered for eCall but with the addition of the
   VEDS MIME type).  This document also describes legacy (circuit-
   switched) ACN systems and their migration to next-generation
   emergency calling, to provide background information and context.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Sep 21 19:04:56 2016
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0034E12BCFF for <ecrit@ietfa.amsl.com>; Wed, 21 Sep 2016 19:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level: 
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_Se0z6drYaE for <ecrit@ietfa.amsl.com>; Wed, 21 Sep 2016 19:04:53 -0700 (PDT)
Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC2712B5DC for <ecrit@ietf.org>; Wed, 21 Sep 2016 19:04:52 -0700 (PDT)
Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-11v.sys.comcast.net with SMTP id mtNWbiGsAlSxsmtNcbkFy0; Thu, 22 Sep 2016 02:04:52 +0000
Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-08v.sys.comcast.net with SMTP id mtNbbvmOui2gemtNbbvTua; Thu, 22 Sep 2016 02:04:52 +0000
To: ecrit@ietf.org
References: <147449984691.14574.14733945301450103878.idtracker@ietfa.amsl.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <728511ac-d655-936c-4044-2bf65a943f95@alum.mit.edu>
Date: Wed, 21 Sep 2016 22:04:51 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <147449984691.14574.14733945301450103878.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfMUvqiXZekQFAofZcowtEnOTT89gTx/B40KVjNV6coRyJyCP4GC0Z33zJJkoONIhGp1E1YC4okbhaYMGqJDBwokM+f4m/vFwOYabwqYh4Upf9Bd5xzgp MGaifBl8B5mhO1mZkcSz20pDyw6VrNTUT95pMdBf5mYCN9fVPzDOLeqv
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/GCGEHJfvkmiJiqS09x4jPJHEphA>
Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-10.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Sep 2016 02:04:55 -0000

Some initial comments during my first pass reading the diffs:

* Section 12:

The Content-Disposition of "Info-package" (applying to the 
multipart/mixed) is wrong, since this isn't an INFO message.  I forget 
if there was clear guidance on what C-D to use on a multipart/mixed 
wrapper. I think you can let it default to render.

I also see that the presence body referenced by the geolocation header 
doesn't have a Content-Disposition. It ought to be "by-reference", even 
though RFC6442 fails to specify that.

	Thanks,
	Paul

On 9/21/16 7:17 PM, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Emergency Context Resolution with Internet Technologies of the IETF.
>
>         Title           : Next-Generation Vehicle-Initiated Emergency Calls
>         Authors         : Randall Gellens
>                           Brian Rosen
>                           Hannes Tschofenig
> 	Filename        : draft-ietf-ecrit-car-crash-10.txt
> 	Pages           : 42
> 	Date            : 2016-09-21
>
> Abstract:
>    This document describes how to use IP-based emergency services
>    mechanisms to support the next generation of emergency calls placed
>    by vehicles (automatically in the event of a crash or serious
>    incident, or manually invoked by a vehicle occupant) and conveying
>    vehicle, sensor, and location data related to the crash or incident.
>    Such calls are often referred to as "Automatic Crash Notification"
>    (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the
>    case of manual trigger.  The "Advanced" qualifier refers to the
>    ability to carry a richer set of data.
>
>    This document also registers a MIME Content Type and Emergency Call
>    Additional Data Block for the vehicle, sensor, and location data
>    (often referred to as "crash data" even though there is not
>    necessarily a crash).  An external specification for the data format,
>    contents, and structure are referenced in this document.
>
>    This document reuses the technical aspects of next-generation pan-
>    European eCall (a mandated and standardized system for emergency
>    calls by in-vehicle systems within Europe and other regions).
>    However, this document specifies a different set of vehicle (crash)
>    data, specifically, the Vehicle Emergency Data Set (VEDS) rather than
>    the eCall Minimum Set of Data (MSD).  This document is an extension
>    of the eCall document, with the primary differences being that this
>    document makes the MSD data set optional and VEDS mandatory, and adds
>    attribute values to the eCall metadata/control object to permit
>    greater functionality.  This document registers a new INFO package
>    (identical to that registered for eCall but with the addition of the
>    VEDS MIME type).  This document also describes legacy (circuit-
>    switched) ACN systems and their migration to next-generation
>    emergency calling, to provide background information and context.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-10
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-10
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>


From nobody Thu Sep 22 12:08:42 2016
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6044912B535 for <ecrit@ietfa.amsl.com>; Thu, 22 Sep 2016 12:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level: 
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2kQMMJsL5zW for <ecrit@ietfa.amsl.com>; Thu, 22 Sep 2016 12:08:39 -0700 (PDT)
Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10FB912B469 for <ecrit@ietf.org>; Thu, 22 Sep 2016 12:08:38 -0700 (PDT)
Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-10v.sys.comcast.net with SMTP id n9LabhIJoHqoln9MLboB1L; Thu, 22 Sep 2016 19:08:37 +0000
Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-08v.sys.comcast.net with SMTP id n9MKbRENlnH9On9MKbDOJr; Thu, 22 Sep 2016 19:08:37 +0000
To: Randall Gellens <rg+ietf@randy.pensive.org>
References: <147449984691.14574.14733945301450103878.idtracker@ietfa.amsl.com> <728511ac-d655-936c-4044-2bf65a943f95@alum.mit.edu> <p06240600d409b441e5b4@[99.111.97.136]>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <6340414c-9e49-0234-69a1-2e4bd346225d@alum.mit.edu>
Date: Thu, 22 Sep 2016 15:08:36 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <p06240600d409b441e5b4@[99.111.97.136]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfJS6tZU1qXTDsY1hYS1eZoo3j07cTAUzI4/oItDs2/6otlly5PAjI9oYXmlmF7yQ1AOE+n4LHhHucciY3iho/wSMK1ITEZZqFCjTYyB71lzVVNFKTQAL pmXQCa6bcPhanvkKNxR5O7LoC1KetEOaEpWGcEhIMdQdW/AKOXrNkMpzKyZ9YhwFZMmcoKvJu0F0wjxHm9uH5zM/5sHetXwX0WI=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/RAldC0B_qHHGnmAheEUvAhs0sis>
Cc: ECRIT <ecrit@ietf.org>
Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-10.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Sep 2016 19:08:40 -0000

Randall,

(Including ecrit)

On 9/22/16 12:26 PM, Randall Gellens wrote:
> Hi Paul,
>
> Thanks very much for the quick review and comments.  I'm making other
> changes requested by Christer, and I want to fix the ones you found as
> well.
>
> Section 12 is the Security Considerations.

In the -10 version I am looking at section 12 is Examples.

> Did you mean Section 11, the
> Examples?  Or maybe Figure 10 (one of the examples)?   More to the point
> on correct C-D, there's text in Section 6 that says:
>
>    If the body part
>    containing the MSD or metadata/control block is the only body part,
>    it has a Content-Disposition header field value of "Info-Package;
>    handling=optional".  If it is contained within a multipart body part,
>    it has a Content-Disposition header field value of "By-Reference;
>    handling=optional".
>
> So this is wrong?  What should it say?

That text seems ok, at least for this case.

IIUC it isn't discussing the C-D *on* the multipart/mixed container. It 
is discussing parts *within* the multipart. Those seem to be correctly 
tagged.

The "Info-Package" C-D is only applicable for an INFO message. Since 
this isn't an INFO message it makes no sense to use it.

The authoritative document on this stuff is RFC5621.  However it is 
silent on what C-D used be used for multipart containers. So it is 
necessary to read between the lines to figure that out.

1) Consider an ordinary INFO message. It will have a body with C-D of 
"Info-Package", indicating that it is to be processed as the package for 
this INFO.

2) Next, add a header that needs to reference a body part, such as 
geolocation. Now we have two body parts, and need a multipart wrapper to 
contain them. One body part has C-D of "Info-Package" for the INFO, and 
the other has C-D of "by-reference" because it is referenced by the 
geolocation header. The multipart that wraps them needs *some* C-D. IMO 
it shouldn't be Info-Package because that would imply that the whole 
thing is to be used by the INFO message. It shouldn't be "by-reference" 
because it isn't referenced by anything. It is really processed in a 
special way, and we have no special C-D value to signify this. If 
omitted it will default to C-D:render,handling=required. Having it be 
required is appropriate in this case, since the handling of the info 
package is also required. The "render" value seems as good as any, since 
the contained parts have their own dispositions and "rendering" a 
multipart independent of its contents also seems to have no meaning.

3) A similar situation to (2) holds for INVITE. In this case of an SDP, 
the default C-D is "session".

4) For some message that doesn't require a body part for its own 
processing (e.g., UPDATE) and a single header with a CID reference. Then 
there will be no multipart - just the referenced part. It will still 
have a C-D of by-reference.

5) A message with no body part of its own, but multiple CID references 
from headers to body parts, will need a multipart body containing the 
referenced body parts. It will be much like (2) but without the 
Info-Package part.

> Section 10 (the INFO package registration) says:
>
>    If the body part is the only body
>    part, it has a Content-Disposition header field value of "INFO-
>    Package; handling=optional".  If the body part is contained within a
>    multipart body part, it has a Content-Disposition header field value
>    of "By-Reference; handling=optional" (the top-level multipart body
>    part has "INFO-Package" in its Content-Disposition value).
>
> So this is also wrong, especially the parenthetical statement that the
> top-level has a C-D of INFO-Package?  What should it say?

Hopefully the above is sufficient.

> Also, when you say "let it default to render" you mean just omit the C-D
> header field?

Yes. But that must be done with care, since it implies 
handling=required. If processing of the headers with references isn't 
required then that ought to be changed to handling=optional.

	Thanks,
	Paul


From nobody Thu Sep 22 12:55:49 2016
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAFE12B39B for <ecrit@ietfa.amsl.com>; Thu, 22 Sep 2016 12:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTqHR87siBZj for <ecrit@ietfa.amsl.com>; Thu, 22 Sep 2016 12:55:46 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70E012B3B9 for <ecrit@ietf.org>; Thu, 22 Sep 2016 12:55:45 -0700 (PDT)
X-AuditID: c1b4fb2d-1c7ff700000009f7-97-57e4373f7cf5
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by  (Symantec Mail Security) with SMTP id 3B.C5.02551.F3734E75; Thu, 22 Sep 2016 21:55:44 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.32]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0301.000; Thu, 22 Sep 2016 21:55:43 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "ecrit@ietf.org" <ecrit@ietf.org>
Thread-Topic: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-12.txt - Christer's comments
Thread-Index: AdIVCon/pgCN+vV0Si2bOB5nFcD5Wg==
Date: Thu, 22 Sep 2016 19:55:42 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4BCF0EEE@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM2K7nK6D+ZNwgx+HOCwaFz1ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtfTn5kLbotV3J68jKmBsVWoi5GTQ0LARGL2t+XsILaQwHpG iW3vw7sYuYDsxYwSjfNuM3YxcnCwCVhIdP/TBqkREVCV2HBmJSOILSwQJnGmdS87RDxc4tGH zUwQtp7E6bV32EBsFqD670/ngNXzCvhKXL94ACzOKCAm8f3UGrB6ZgFxiVtP5jNB3CMgsWTP eWYIW1Ti5eN/rBC2ksSK7ZcYIep1JBbs/sQGYWtLLFv4mhlivqDEyZlPWCYwCs1CMnYWkpZZ SFpmIWlZwMiyilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwkA9u+a27g3H1a8dDjAIcjEo8 vA8ePw4XYk0sK67MPcQowcGsJMKbqfUkXIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr74UIC 6YklqdmpqQWpRTBZJg5OqQZGkwsHPp2cUVGRdrllt3tYwIw9DmLVO/7pu7dcvK3gH8xRKyWk uXzH7EPJn8z1us3k30imr0+RPPnn41zlV5PSWabmbD2vJLbStJK/abewaW7Sdp5fz37yFMQf Cal1SD5sc++PcGvl6YnMb2czNB99fFLgy7c5pvy62TY32bfV2mbGOizN2LBdiaU4I9FQi7mo OBEAxYB7D2ACAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/UQ0amaxjDc_C_IO2_2RDmVAzAfw>
Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-12.txt - Christer's comments
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Sep 2016 19:55:48 -0000

Hi,

I gave some comments on the draft to Randall before it was published, and h=
e has addressed much of it.

Apart from some editorial comments that I still have, my main issue is stil=
l section 6.

My proposal was that we describe both mechanisms (for INFOs and for non-INF=
Os). Then, when we describe the mechanism for INFO (i.e., usage of info pac=
kage) we describe that the Call-Info etc can be used to align etc (that has=
 also been done in Section 10, which defines the info package).

But, section 6 contains 3 paragraphs talking about the additional data mech=
anism, and then there is one sentence that mentions INFO.

My suggestion is to separate section 6 into sub sections: one general, one =
describing the additional data mechanism, and one describing the info packa=
ge mechanism.

Regards,

Christer


-----Original Message-----
From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of internet-drafts@ie=
tf.org
Sent: 22 September 2016 02:17
To: i-d-announce@ietf.org
Cc: ecrit@ietf.org
Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-12.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
This draft is a work item of the Emergency Context Resolution with Internet=
 Technologies of the IETF.

        Title           : Next-Generation Pan-European eCall
        Authors         : Randall Gellens
                          Hannes Tschofenig
	Filename        : draft-ietf-ecrit-ecall-12.txt
	Pages           : 43
	Date            : 2016-09-21

Abstract:
   This document describes how to use IP-based emergency services
   mechanisms to support the next generation of the Pan European in-
   vehicle emergency call service defined under the eSafety initiative
   of the European Commission (generally referred to as "eCall"). eCall
   is a standardized and mandated system for a special form of emergency
   calls placed by vehicles, providing real-time communications and an
   integrated set of related data.

   This document also registers MIME Content Types and an Emergency Call
   Additional Data Blocks for the eCall vehicle data and metadata/
   control data.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ecrit-ecall-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-ecall-12


Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


From nobody Thu Sep 22 14:46:40 2016
Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD4C12BB86 for <ecrit@ietfa.amsl.com>; Thu, 22 Sep 2016 14:46:39 -0700 (PDT)
X-Quarantine-ID: <Mbuu-edYHTPG>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -4.216
X-Spam-Level: 
X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mbuu-edYHTPG for <ecrit@ietfa.amsl.com>; Thu, 22 Sep 2016 14:46:37 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA5512BB70 for <ecrit@ietf.org>; Thu, 22 Sep 2016 14:46:37 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 22 Sep 2016 14:46:36 -0700
Mime-Version: 1.0
Message-Id: <p0624060cd409f3ccca4a@[99.111.97.136]>
In-Reply-To: <6340414c-9e49-0234-69a1-2e4bd346225d@alum.mit.edu>
References: <147449984691.14574.14733945301450103878.idtracker@ietfa.amsl.com> <728511ac-d655-936c-4044-2bf65a943f95@alum.mit.edu> <p06240600d409b441e5b4@[99.111.97.136]> <6340414c-9e49-0234-69a1-2e4bd346225d@alum.mit.edu>
X-Mailer: Eudora for Mac OS X
Date: Thu, 22 Sep 2016 14:46:34 -0700
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
From: Randall Gellens <rg+ietf@randy.pensive.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/IngKSGDcM_tKVV7l4WL-C0AkRy8>
Cc: ECRIT <ecrit@ietf.org>
Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-10.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Sep 2016 21:46:39 -0000

At 3:08 PM -0400 9/22/16, Paul Kyzivat wrote:

>  Randall,
>
>  (Including ecrit)
>
>  On 9/22/16 12:26 PM, Randall Gellens wrote:
>>  Hi Paul,
>>
>>  Thanks very much for the quick review and comments.  I'm making other
>>  changes requested by Christer, and I want to fix the ones you found as
>>  well.
>>
>>  Section 12 is the Security Considerations.
>
>  In the -10 version I am looking at section 12 is Examples.

Sorry, I missed that you were replying to -10; I'd incorrectly 
assumed you were replying to -12.

>
>>  Did you mean Section 11, the
>>  Examples?  Or maybe Figure 10 (one of the examples)?   More to the point
>>  on correct C-D, there's text in Section 6 that says:
>>
>>     If the body part
>>     containing the MSD or metadata/control block is the only body part,
>>     it has a Content-Disposition header field value of "Info-Package;
>>     handling=optional".  If it is contained within a multipart body part,
>>     it has a Content-Disposition header field value of "By-Reference;
>>     handling=optional".
>>
>>  So this is wrong?  What should it say?
>
>  That text seems ok, at least for this case.
>
>  IIUC it isn't discussing the C-D *on* the multipart/mixed 
> container. It is discussing parts *within* the multipart. Those 
> seem to be correctly tagged.
>
>  The "Info-Package" C-D is only applicable for an INFO message. 
> Since this isn't an INFO message it makes no sense to use it.

That was fixed in -12.

I'm about to upload -13, which fixes the C-D issues.  I also added 
text to clarify that "handling=optional" is only used in the initial 
INVITE, to protect the INVITE from being rejected if it is processed 
by a legacy element (such as a gateway between SIP and CS) that does 
not understand an MSD.  I fixed the examples to comply.

>
>  The authoritative document on this stuff is RFC5621.  However it is 
> silent on what C-D used be used for multipart containers. So it is 
> necessary to read between the lines to figure that out.
>
>  1) Consider an ordinary INFO message. It will have a body with C-D 
> of "Info-Package", indicating that it is to be processed as the 
> package for this INFO.
>
>  2) Next, add a header that needs to reference a body part, such as 
> geolocation. Now we have two body parts, and need a multipart 
> wrapper to contain them. One body part has C-D of "Info-Package" 
> for the INFO, and the other has C-D of "by-reference" because it is 
> referenced by the geolocation header. The multipart that wraps them 
> needs *some* C-D. IMO it shouldn't be Info-Package because that 
> would imply that the whole thing is to be used by the INFO message. 
> It shouldn't be "by-reference" because it isn't referenced by 
> anything. It is really processed in a special way, and we have no 
> special C-D value to signify this. If omitted it will default to 
> C-D:render,handling=required. Having it be required is appropriate 
> in this case, since the handling of the info package is also 
> required. The "render" value seems as good as any, since the 
> contained parts have their own dispositions and "rendering" a 
> multipart independent of its contents also seems to have no meaning.
>
>  3) A similar situation to (2) holds for INVITE. In this case of an 
> SDP, the default C-D is "session".
>
>  4) For some message that doesn't require a body part for its own 
> processing (e.g., UPDATE) and a single header with a CID reference. 
> Then there will be no multipart - just the referenced part. It will 
> still have a C-D of by-reference.
>
>  5) A message with no body part of its own, but multiple CID 
> references from headers to body parts, will need a multipart body 
> containing the referenced body parts. It will be much like (2) but 
> without the Info-Package part.
>
>>  Section 10 (the INFO package registration) says:
>>
>>     If the body part is the only body
>>     part, it has a Content-Disposition header field value of "INFO-
>>     Package; handling=optional".  If the body part is contained within a
>>     multipart body part, it has a Content-Disposition header field value
>>     of "By-Reference; handling=optional" (the top-level multipart body
>>     part has "INFO-Package" in its Content-Disposition value).
>>
>>  So this is also wrong, especially the parenthetical statement that the
>>  top-level has a C-D of INFO-Package?  What should it say?
>
>  Hopefully the above is sufficient.
>
>>  Also, when you say "let it default to render" you mean just omit the C-D
>>  header field?
>
>  Yes. But that must be done with care, since it implies 
> handling=required. If processing of the headers with references 
> isn't required then that ought to be changed to handling=optional.
>
>  	Thanks,
>  	Paul


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
After years of disclosures by government investigations, media accounts,
and reports from human rights organizations, there is no longer any
doubt as to whether the current [George W Bush] administration has
committed war crimes.  The only question that remains to be answered is
whether those who ordered the use of torture will be held to account.
                    -- Major General Anthony Taguba, US Army (ret)


From nobody Thu Sep 22 15:16:00 2016
Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD1E12B96C for <ecrit@ietfa.amsl.com>; Thu, 22 Sep 2016 15:15:59 -0700 (PDT)
X-Quarantine-ID: <VG_n9OQwK9lJ>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -4.216
X-Spam-Level: 
X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VG_n9OQwK9lJ for <ecrit@ietfa.amsl.com>; Thu, 22 Sep 2016 15:15:58 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id E307112B946 for <ecrit@ietf.org>; Thu, 22 Sep 2016 15:15:57 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 22 Sep 2016 15:15:57 -0700
Mime-Version: 1.0
Message-Id: <p0624060dd40a07a57125@[99.111.97.136]>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BCF0EEE@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B4BCF0EEE@ESESSMB209.ericsson.se>
X-Mailer: Eudora for Mac OS X
Date: Thu, 22 Sep 2016 15:15:55 -0700
To: Christer Holmberg <christer.holmberg@ericsson.com>, "ecrit@ietf.org" <ecrit@ietf.org>
From: Randall Gellens <rg+ietf@randy.pensive.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/3beyNHhzNXT2Y-pJluAEMtfW5CY>
Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-12.txt - Christer's comments
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Sep 2016 22:16:00 -0000

Hi Christer,

At 7:55 PM +0000 9/22/16, Christer Holmberg wrote:

>  Hi,
>
>  I gave some comments on the draft to Randall before it was 
> published, and he has addressed much of it.
>
>  Apart from some editorial comments that I still have, my main issue 
> is still section 6.
>
>  My proposal was that we describe both mechanisms (for INFOs and for 
> non-INFOs). Then, when we describe the mechanism for INFO (i.e., 
> usage of info package) we describe that the Call-Info etc can be 
> used to align etc (that has also been done in Section 10, which 
> defines the info package).
>
>  But, section 6 contains 3 paragraphs talking about the additional 
> data mechanism, and then there is one sentence that mentions INFO.

There are multiple references to INFO.  I think there are more 
references to INFO than without.  More importantly, per your 
suggestion, each place that mentions Call-Info says that the body 
part is sent in INFO using the INFO package defined in 10, per 
RFC6086.

Please have a look at -13, which I will upload soon.  It makes the 
further changes you suggested based on -12, and I did another 
read-through to find other places where transport or Call-Info or 
INFO are mentioned to be sure it is clear that body part are sent in 
INFO per RFC 6086 and using the INFO package.


>
>  My suggestion is to separate section 6 into sub sections: one 
> general, one describing the additional data mechanism, and one 
> describing the info package mechanism.
>
>  Regards,
>
>  Christer
>
>
>  -----Original Message-----
>  From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of 
> internet-drafts@ietf.org
>  Sent: 22 September 2016 02:17
>  To: i-d-announce@ietf.org
>  Cc: ecrit@ietf.org
>  Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-12.txt
>
>
>  A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>  This draft is a work item of the Emergency Context Resolution with 
> Internet Technologies of the IETF.
>
>          Title           : Next-Generation Pan-European eCall
>          Authors         : Randall Gellens
>                            Hannes Tschofenig
>  	Filename        : draft-ietf-ecrit-ecall-12.txt
>  	Pages           : 43
>  	Date            : 2016-09-21
>
>  Abstract:
>     This document describes how to use IP-based emergency services
>     mechanisms to support the next generation of the Pan European in-
>     vehicle emergency call service defined under the eSafety initiative
>     of the European Commission (generally referred to as "eCall"). eCall
>     is a standardized and mandated system for a special form of emergency
>     calls placed by vehicles, providing real-time communications and an
>     integrated set of related data.
>
>     This document also registers MIME Content Types and an Emergency Call
>     Additional Data Blocks for the eCall vehicle data and metadata/
>     control data.
>
>
>  The IETF datatracker status page for this draft is:
>  https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/
>
>  There's also a htmlized version available at:
>  https://tools.ietf.org/html/draft-ietf-ecrit-ecall-12
>
>  A diff from the previous version is available at:
>  https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-12
>
>
>  Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
>
>  Internet-Drafts are also available by anonymous FTP at:
>  ftp://ftp.ietf.org/internet-drafts/
>
>  _______________________________________________
>  Ecrit mailing list
>  Ecrit@ietf.org
>  https://www.ietf.org/mailman/listinfo/ecrit
>
>  _______________________________________________
>  Ecrit mailing list
>  Ecrit@ietf.org
>  https://www.ietf.org/mailman/listinfo/ecrit


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Good night to spend with family, but avoid arguments with your
mate's new lover.


From nobody Thu Sep 22 15:25:55 2016
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A317E12BF22 for <ecrit@ietfa.amsl.com>; Thu, 22 Sep 2016 15:25:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level: 
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvCTyhYT47D5 for <ecrit@ietfa.amsl.com>; Thu, 22 Sep 2016 15:25:52 -0700 (PDT)
Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7547312BF10 for <ecrit@ietf.org>; Thu, 22 Sep 2016 15:25:52 -0700 (PDT)
Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-10v.sys.comcast.net with SMTP id nCRBbXqP5RingnCRDbp4do; Thu, 22 Sep 2016 22:25:51 +0000
Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-09v.sys.comcast.net with SMTP id nCRDbzUePN3QMnCRDbIM02; Thu, 22 Sep 2016 22:25:51 +0000
To: Randall Gellens <rg+ietf@randy.pensive.org>
References: <147449984691.14574.14733945301450103878.idtracker@ietfa.amsl.com> <728511ac-d655-936c-4044-2bf65a943f95@alum.mit.edu> <p06240600d409b441e5b4@[99.111.97.136]> <6340414c-9e49-0234-69a1-2e4bd346225d@alum.mit.edu> <p0624060cd409f3ccca4a@[99.111.97.136]>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <20fe1acb-4ba0-d9ce-cf93-3e09ef3a3378@alum.mit.edu>
Date: Thu, 22 Sep 2016 18:25:50 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <p0624060cd409f3ccca4a@[99.111.97.136]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfOpvqfabtq5bc8RgK5/e23XKv1cJ3pcHUVKvSbfZY3CAmWlQP1fIN6+m3wobgfud4Twjr7aEzBlQXF/rNvF1ueosRwah6UlQ/D9/n4RFZF5j024NJRmC i1eehsI6g7uW55o2b18MayrRmXfR+BFKuRqSN2LtT3SW6RtStfCSbS+SHOD5CDRr7FRZCHnzkhuZdJ2g20k/fFKiUfvij4u9B54=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/Wi-dfFcIdwu2qKpUQSAhW1kpljw>
Cc: ECRIT <ecrit@ietf.org>
Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-10.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Sep 2016 22:25:53 -0000

see end

On 9/22/16 5:46 PM, Randall Gellens wrote:
> At 3:08 PM -0400 9/22/16, Paul Kyzivat wrote:
>
>>  Randall,
>>
>>  (Including ecrit)
>>
>>  On 9/22/16 12:26 PM, Randall Gellens wrote:
>>>  Hi Paul,
>>>
>>>  Thanks very much for the quick review and comments.  I'm making other
>>>  changes requested by Christer, and I want to fix the ones you found as
>>>  well.
>>>
>>>  Section 12 is the Security Considerations.
>>
>>  In the -10 version I am looking at section 12 is Examples.
>
> Sorry, I missed that you were replying to -10; I'd incorrectly assumed
> you were replying to -12.
>
>>
>>>  Did you mean Section 11, the
>>>  Examples?  Or maybe Figure 10 (one of the examples)?   More to the
>>> point
>>>  on correct C-D, there's text in Section 6 that says:
>>>
>>>     If the body part
>>>     containing the MSD or metadata/control block is the only body part,
>>>     it has a Content-Disposition header field value of "Info-Package;
>>>     handling=optional".  If it is contained within a multipart body
>>> part,
>>>     it has a Content-Disposition header field value of "By-Reference;
>>>     handling=optional".
>>>
>>>  So this is wrong?  What should it say?
>>
>>  That text seems ok, at least for this case.
>>
>>  IIUC it isn't discussing the C-D *on* the multipart/mixed container.
>> It is discussing parts *within* the multipart. Those seem to be
>> correctly tagged.
>>
>>  The "Info-Package" C-D is only applicable for an INFO message. Since
>> this isn't an INFO message it makes no sense to use it.
>
> That was fixed in -12.
>
> I'm about to upload -13, which fixes the C-D issues.  I also added text
> to clarify that "handling=optional" is only used in the initial INVITE,
> to protect the INVITE from being rejected if it is processed by a legacy
> element (such as a gateway between SIP and CS) that does not understand
> an MSD.  I fixed the examples to comply.

handling=optional is probably wrong on the multipart for an INVITE that 
contains an SDP offer. The processing of the SDP isn't optional, and if 
you encounter a UAS that doesn't support multipart then you want it to 
fail, not to be treated as an INVITE with no offer.

	Thanks,
	Paul


From nobody Thu Sep 22 15:32:51 2016
Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801E112BFD0 for <ecrit@ietfa.amsl.com>; Thu, 22 Sep 2016 15:32:49 -0700 (PDT)
X-Quarantine-ID: <NZtrCKWsxqa4>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -4.216
X-Spam-Level: 
X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZtrCKWsxqa4 for <ecrit@ietfa.amsl.com>; Thu, 22 Sep 2016 15:32:47 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B1A8712BFCD for <ecrit@ietf.org>; Thu, 22 Sep 2016 15:32:47 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 22 Sep 2016 15:32:47 -0700
Mime-Version: 1.0
Message-Id: <p0624060ed40a0c037738@[99.111.97.136]>
In-Reply-To: <20fe1acb-4ba0-d9ce-cf93-3e09ef3a3378@alum.mit.edu>
References: <147449984691.14574.14733945301450103878.idtracker@ietfa.amsl.com> <728511ac-d655-936c-4044-2bf65a943f95@alum.mit.edu> <p06240600d409b441e5b4@[99.111.97.136]> <6340414c-9e49-0234-69a1-2e4bd346225d@alum.mit.edu> <p0624060cd409f3ccca4a@[99.111.97.136]> <20fe1acb-4ba0-d9ce-cf93-3e09ef3a3378@alum.mit.edu>
X-Mailer: Eudora for Mac OS X
Date: Thu, 22 Sep 2016 15:32:45 -0700
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
From: Randall Gellens <rg+ietf@randy.pensive.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/YCJsvX9J2BGJbOfG9KvttE5xlFw>
Cc: ECRIT <ecrit@ietf.org>
Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-10.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Sep 2016 22:32:49 -0000

At 6:25 PM -0400 9/22/16, Paul Kyzivat wrote:

>  see end
>
>  On 9/22/16 5:46 PM, Randall Gellens wrote:
>>  At 3:08 PM -0400 9/22/16, Paul Kyzivat wrote:
>>
>>>   Randall,
>>>
>>>   (Including ecrit)
>>>
>>>   On 9/22/16 12:26 PM, Randall Gellens wrote:
>>>>   Hi Paul,
>>>>
>>>>   Thanks very much for the quick review and comments.  I'm making other
>>>>   changes requested by Christer, and I want to fix the ones you found as
>>>>   well.
>>>>
>>>>   Section 12 is the Security Considerations.
>>>
>>>   In the -10 version I am looking at section 12 is Examples.
>>
>>  Sorry, I missed that you were replying to -10; I'd incorrectly assumed
>>  you were replying to -12.
>>
>>>
>>>>   Did you mean Section 11, the
>>>>   Examples?  Or maybe Figure 10 (one of the examples)?   More to the
>>>>  point
>>>>   on correct C-D, there's text in Section 6 that says:
>>>>
>>>>      If the body part
>>>>      containing the MSD or metadata/control block is the only body part,
>>>>      it has a Content-Disposition header field value of "Info-Package;
>>>>      handling=optional".  If it is contained within a multipart body
>>>>  part,
>>>>      it has a Content-Disposition header field value of "By-Reference;
>>>>      handling=optional".
>>>>
>>>>   So this is wrong?  What should it say?
>>>
>>>   That text seems ok, at least for this case.
>>>
>>>   IIUC it isn't discussing the C-D *on* the multipart/mixed container.
>>>  It is discussing parts *within* the multipart. Those seem to be
>>>  correctly tagged.
>>>
>>>   The "Info-Package" C-D is only applicable for an INFO message. Since
>>>  this isn't an INFO message it makes no sense to use it.
>>
>>  That was fixed in -12.
>>
>>  I'm about to upload -13, which fixes the C-D issues.  I also added text
>>  to clarify that "handling=optional" is only used in the initial INVITE,
>>  to protect the INVITE from being rejected if it is processed by a legacy
>>  element (such as a gateway between SIP and CS) that does not understand
>>  an MSD.  I fixed the examples to comply.
>
>  handling=optional is probably wrong on the multipart for an INVITE 
> that contains an SDP offer. The processing of the SDP isn't 
> optional, and if you encounter a UAS that doesn't support multipart 
> then you want it to fail, not to be treated as an INVITE with no 
> offer.

Sorry for not being clear in my earlier message; the clarifications 
in the draft say that "handling=optional" in the initial INVITE 
applies to the MSD (in eCall), the VEDS (in car-crash), and the 
metadata/control object (in both) and the PIDF-LO.  It doesn't apply 
to the SDP nor the enclosing multipart, for the reasons you state.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
. . . It wasn't until the jet engine came into being and that
engine was coupled with special airplane designs - such as the
swept wing - that airplanes finally achieved a high enough work
capability, efficiency and comfort level to allow air
transportation to really take off.
        --Joseph F. Sutter, Boeing Commercial Airplanes


From nobody Thu Sep 22 20:15:23 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: ecrit@ietf.org
Delivered-To: ecrit@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E24512B91E; Thu, 22 Sep 2016 20:15:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.33.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147460051915.22446.3905020998297020767.idtracker@ietfa.amsl.com>
Date: Thu, 22 Sep 2016 20:15:19 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/O6pruKUw-pAQp_GufCkPk6UrK3I>
Cc: ecrit@ietf.org
Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-13.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Sep 2016 03:15:19 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Emergency Context Resolution with Internet Technologies of the IETF.

        Title           : Next-Generation Pan-European eCall
        Authors         : Randall Gellens
                          Hannes Tschofenig
	Filename        : draft-ietf-ecrit-ecall-13.txt
	Pages           : 43
	Date            : 2016-09-22

Abstract:
   This document describes how to use IP-based emergency services
   mechanisms to support the next generation of the Pan European in-
   vehicle emergency call service defined under the eSafety initiative
   of the European Commission (generally referred to as "eCall"). eCall
   is a standardized and mandated system for a special form of emergency
   calls placed by vehicles, providing real-time communications and an
   integrated set of related data.

   This document also registers MIME Content Types and an Emergency Call
   Additional Data Blocks for the eCall vehicle data and metadata/
   control data.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ecrit-ecall-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Sep 22 20:18:40 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: ecrit@ietf.org
Delivered-To: ecrit@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 953E012B784; Thu, 22 Sep 2016 20:18:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.33.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147460071860.22446.2297178978097588073.idtracker@ietfa.amsl.com>
Date: Thu, 22 Sep 2016 20:18:38 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/B_gsUcyKx0S8gvB2YWf8-u8j1S8>
Cc: ecrit@ietf.org
Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-11.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Sep 2016 03:18:38 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Emergency Context Resolution with Internet Technologies of the IETF.

        Title           : Next-Generation Vehicle-Initiated Emergency Calls
        Authors         : Randall Gellens
                          Brian Rosen
                          Hannes Tschofenig
	Filename        : draft-ietf-ecrit-car-crash-11.txt
	Pages           : 42
	Date            : 2016-09-22

Abstract:
   This document describes how to use IP-based emergency services
   mechanisms to support the next generation of emergency calls placed
   by vehicles (automatically in the event of a crash or serious
   incident, or manually invoked by a vehicle occupant) and conveying
   vehicle, sensor, and location data related to the crash or incident.
   Such calls are often referred to as "Automatic Crash Notification"
   (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the
   case of manual trigger.  The "Advanced" qualifier refers to the
   ability to carry a richer set of data.

   This document also registers a MIME Content Type and Emergency Call
   Additional Data Block for the vehicle, sensor, and location data
   (often referred to as "crash data" even though there is not
   necessarily a crash).  An external specification for the data format,
   contents, and structure are referenced in this document.

   This document reuses the technical aspects of next-generation pan-
   European eCall (a mandated and standardized system for emergency
   calls by in-vehicle systems within Europe and other regions).
   However, this document specifies a different set of vehicle (crash)
   data, specifically, the Vehicle Emergency Data Set (VEDS) rather than
   the eCall Minimum Set of Data (MSD).  This document is an extension
   of the eCall document, with the primary differences being that this
   document makes the MSD data set optional and VEDS mandatory, and adds
   attribute values to the eCall metadata/control object to permit
   greater functionality.  This document registers a new INFO package
   (identical to that registered for eCall but with the addition of the
   VEDS MIME type).  This document also describes legacy (circuit-
   switched) ACN systems and their migration to next-generation
   emergency calling, to provide background information and context.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-11


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Sep 23 01:00:08 2016
Return-Path: <ivo.sedlacek@ericsson.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2E612B54F for <ecrit@ietfa.amsl.com>; Fri, 23 Sep 2016 01:00:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqnCzhNPvaCN for <ecrit@ietfa.amsl.com>; Fri, 23 Sep 2016 01:00:00 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0978912D796 for <ecrit@ietf.org>; Fri, 23 Sep 2016 00:50:23 -0700 (PDT)
X-AuditID: c1b4fb2d-1c7ff700000009f7-53-57e4debdc465
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by  (Symantec Mail Security) with SMTP id 01.D2.02551.DBED4E75; Fri, 23 Sep 2016 09:50:22 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.61]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0301.000; Fri, 23 Sep 2016 09:50:21 +0200
From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
To: "ecrit@ietf.org" <ecrit@ietf.org>
Thread-Topic: draft-ietf-ecrit-ecall-13- Changes of MIME type, XML namespace and XML element for eCall
Thread-Index: AdIVbxh7HA2mDf54TI+A3muo95vigg==
Date: Fri, 23 Sep 2016 07:50:20 +0000
Message-ID: <39B5E4D390E9BD4890E2B310790061011655CC18@ESESSMB301.ericsson.se>
Accept-Language: en-US, cs-CZ
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.147]
Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B310790061011655CC18ESESSMB301erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM2K7q+6+e0/CDU5NlbFoXPSU1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGeve8BU816x4cXcSYwPjfNUuRk4OCQETid/n/7J3MXJxCAms Z5T4emwuK0hCSGAxo0TfSn0Qm01AT2LiliNgcREBVYkNZ1YygtjCAskSbfNfskHEMySmLlgH VaMn8aBlHlgNC1D9w9kvwGp4BXwl1pz4CFbDKCArcfVPL1gNs4C4xK0n85kgDhKQWLLnPDOE LSrx8vE/oHoOIFtJYtrWNIjyfIk9T06zQowUlDg58wnLBEbBWUgmzUJSNgtJGURcR2LB7k9s ELa2xLKFr5lh7DMHHjMhiy9gZF/FKFqcWlycm25krJdalJlcXJyfp5eXWrKJERj2B7f81t3B uPq14yFGAQ5GJR7eB48fhwuxJpYVV+YeYpTgYFYS4U2/8SRciDclsbIqtSg/vqg0J7X4EKM0 B4uSOK/ZyvvhQgLpiSWp2ampBalFMFkmDk6pBsY1Px6c62aKuSRsnm+c6rf/OqPI3aOrn6le Ypyu0f8wKfiR2qpXx+4o5F1k8JGSeL00Svy0Go9tXscSd49ju16sdtf3tVj1ecY15xsGe1yL Fsw/mm5aab34tHKf2+aDBQqzUt7tiF5YYagct5Vj1TPl5VpyuRtrrk01UJV+Ff8+/G74P/kf T92UWIozEg21mIuKEwHatNCidwIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/Cx_MCoT9ILHWddzZT5VdoIZiWns>
Subject: [Ecrit] draft-ietf-ecrit-ecall-13- Changes of MIME type, XML namespace and XML element for eCall
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Sep 2016 08:00:04 -0000

--_000_39B5E4D390E9BD4890E2B310790061011655CC18ESESSMB301erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,



I noticed that the MIME type, XML namespace and XML element were changed be=
tween -11 and -13.

                -11 specified "application/emergencyCallData.eCall.control+=
xml" MIME type while -13 specifies "application/emergencyCallData.control+x=
ml" MIME type

                -11 specified "urn:ietf:params:xml:ns:EmergencyCallData:eCa=
ll:control" XML namespace while -13 specifies "urn:ietf:params:xml:ns:Emerg=
encyCallData:control" XML namespace

                -11 specified "EmergencyCallData.eCall.Control" XML element=
 while -13 specifies "emergencyCallData.control" XML element



When was this discussed? And when was this agreed?



Kind regards



Ivo Sedlacek

--_000_39B5E4D390E9BD4890E2B310790061011655CC18ESESSMB301erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">Hello,<o:p></o:p></p>
<p class=3D"MsoPlainText"><span style=3D"color:black"><o:p>&nbsp;</o:p></sp=
an></p>
<p class=3D"MsoPlainText"><span style=3D"color:black">I noticed that the MI=
ME type, XML namespace and XML element were changed between -11 and -13.<o:=
p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"color:black">&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -11 s=
pecified &quot;application/<span style=3D"background:yellow;mso-highlight:y=
ellow">emergencyCallData.eCall.control</span>&#43;xml&quot; MIME type while=
 -13 specifies &quot;application/<span style=3D"background:yellow;mso-highl=
ight:yellow">emergencyCallData.control</span>&#43;xml&quot;
 MIME type<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"color:black">&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -11 s=
pecified &quot;urn:ietf:params:xml:ns:<span style=3D"background:yellow;mso-=
highlight:yellow">EmergencyCallData:eCall:control</span>&quot; XML namespac=
e while -13 specifies &quot;urn:ietf:params:xml:ns:<span style=3D"backgroun=
d:yellow;mso-highlight:yellow">EmergencyCallData:control</span>&quot;
 XML namespace <o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"color:black">&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -11 s=
pecified &quot;<span style=3D"background:yellow;mso-highlight:yellow">Emerg=
encyCallData.eCall.Control</span>&quot; XML element while -13 specifies &qu=
ot;<span style=3D"background:yellow;mso-highlight:yellow">emergencyCallData=
.control</span>&quot;
 XML element <o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"color:black"><o:p>&nbsp;</o:p></sp=
an></p>
<p class=3D"MsoPlainText"><span style=3D"color:black">When was this discuss=
ed? And when was this agreed?
<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span style=3D"color:black"><o:p>&nbsp;</o:p></sp=
an></p>
<p class=3D"MsoPlainText"><span style=3D"color:black">Kind regards<o:p></o:=
p></span></p>
<p class=3D"MsoPlainText"><span style=3D"color:black"><o:p>&nbsp;</o:p></sp=
an></p>
<p class=3D"MsoPlainText"><span style=3D"color:black">Ivo Sedlacek<o:p></o:=
p></span></p>
</div>
</body>
</html>

--_000_39B5E4D390E9BD4890E2B310790061011655CC18ESESSMB301erics_--


From nobody Fri Sep 23 07:54:46 2016
Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA5312B668 for <ecrit@ietfa.amsl.com>; Fri, 23 Sep 2016 07:54:44 -0700 (PDT)
X-Quarantine-ID: <AMxPSYdZxyOU>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -4.216
X-Spam-Level: 
X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMxPSYdZxyOU for <ecrit@ietfa.amsl.com>; Fri, 23 Sep 2016 07:54:42 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 367E212B5B8 for <ecrit@ietf.org>; Fri, 23 Sep 2016 07:54:42 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 23 Sep 2016 07:54:41 -0700
Mime-Version: 1.0
Message-Id: <p06240600d40af229686a@[99.111.97.136]>
In-Reply-To: <39B5E4D390E9BD4890E2B310790061011655CC18@ESESSMB301.ericsson.se>
References: <39B5E4D390E9BD4890E2B310790061011655CC18@ESESSMB301.ericsson.se>
X-Mailer: Eudora for Mac OS X
Date: Fri, 23 Sep 2016 07:54:38 -0700
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>, "ecrit@ietf.org" <ecrit@ietf.org>
From: Randall Gellens <rg+ietf@randy.pensive.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/-tJVpsp_wQT2PGaMlOCk59P_3K0>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-13- Changes of MIME type, XML namespace and XML element for eCall
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Sep 2016 14:54:44 -0000

Hi Ivo, this was changed based on comments that the metadata/control 
object having the name "eCall" was too restrictive.  It seemed like a 
good idea to have it be general.  Do you think it's better the other 
way?

--Randy

At 7:50 AM +0000 9/23/16, Ivo Sedlacek wrote:

>  Hello,
>
>  I noticed that the MIME type, XML namespace and XML element were 
> changed between -11 and -13.
>                  -11 specified 
> "application/emergencyCallData.eCall.control+xml" MIME type while 
> -13 specifies "application/emergencyCallData.control+xml" MIME type
>                  -11 specified 
> "urn:ietf:params:xml:ns:EmergencyCallData:eCall:control" XML 
> namespace while -13 specifies 
> "urn:ietf:params:xml:ns:EmergencyCallData:control" XML namespace
>                  -11 specified "EmergencyCallData.eCall.Control" XML 
> element while -13 specifies "emergencyCallData.control" XML element
>
>  When was this discussed? And when was this agreed?
>
>  Kind regards
>
>  Ivo Sedlacek
>
>  _______________________________________________
>  Ecrit mailing list
>  Ecrit@ietf.org
>  https://www.ietf.org/mailman/listinfo/ecrit


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Intelligence and war are games, perhaps the only meaningful games
left.  If any player becomes too proficient, the game is threatened
with termination.                           --William S. Burroughs


From nobody Sat Sep 24 20:12:21 2016
Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B2A12B0B7 for <ecrit@ietfa.amsl.com>; Sat, 24 Sep 2016 20:12:20 -0700 (PDT)
X-Quarantine-ID: <oXmNMjW2if3D>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -4.216
X-Spam-Level: 
X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXmNMjW2if3D for <ecrit@ietfa.amsl.com>; Sat, 24 Sep 2016 20:12:19 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B57BE12B0B6; Sat, 24 Sep 2016 20:12:19 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sat, 24 Sep 2016 20:12:19 -0700
Mime-Version: 1.0
Message-Id: <p06240602d40cefd4dd4c@[99.111.97.136]>
In-Reply-To: <147460051915.22446.3905020998297020767.idtracker@ietfa.amsl.com> <147460071860.22446.2297178978097588073.idtracker@ietfa.amsl.com>
References: <147460051915.22446.3905020998297020767.idtracker@ietfa.amsl.com> <147460071860.22446.2297178978097588073.idtracker@ietfa.amsl.com>
X-Mailer: Eudora for Mac OS X
Date: Sat, 24 Sep 2016 20:11:45 -0700
To: ecrit@ietf.org
From: Randall Gellens <rg+ietf@randy.pensive.org>
Cc: ecrit@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/45hooZK3nWIZFYn6oHSKyQ1pYrE>
Subject: [Ecrit] draft-ietf-ecrit-ecall-13 & draft-ietf-ecrit-car-crash-11
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Sep 2016 03:12:20 -0000

Hi ECRIT,

The versions draft-ietf-ecrit-ecall-13 & 
draft-ietf-ecrit-car-crash-11 address all comments.

--Randy


From nobody Sun Sep 25 20:21:14 2016
Return-Path: <internet-drafts@ietf.org>
X-Original-To: ecrit@ietf.org
Delivered-To: ecrit@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5E212B077; Sun, 25 Sep 2016 20:21:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.34.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147486007282.28315.5048577746882429216.idtracker@ietfa.amsl.com>
Date: Sun, 25 Sep 2016 20:21:12 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/6eZ-ZtT5l4lBR_oV0MOyk3lNGU8>
Cc: ecrit@ietf.org
Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-12.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2016 03:21:13 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Emergency Context Resolution with Internet Technologies of the IETF.

        Title           : Next-Generation Vehicle-Initiated Emergency Calls
        Authors         : Randall Gellens
                          Brian Rosen
                          Hannes Tschofenig
	Filename        : draft-ietf-ecrit-car-crash-12.txt
	Pages           : 42
	Date            : 2016-09-25

Abstract:
   This document describes how to use IP-based emergency services
   mechanisms to support the next generation of emergency calls placed
   by vehicles (automatically in the event of a crash or serious
   incident, or manually invoked by a vehicle occupant) and conveying
   vehicle, sensor, and location data related to the crash or incident.
   Such calls are often referred to as "Automatic Crash Notification"
   (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the
   case of manual trigger.  The "Advanced" qualifier refers to the
   ability to carry a richer set of data.

   This document also registers a MIME Content Type and Emergency Call
   Additional Data Block for the vehicle, sensor, and location data
   (often referred to as "crash data" even though there is not
   necessarily a crash).  An external specification for the data format,
   contents, and structure are referenced in this document.

   This document reuses the technical aspects of next-generation pan-
   European eCall (a mandated and standardized system for emergency
   calls by in-vehicle systems within Europe and other regions).
   However, this document specifies a different set of vehicle (crash)
   data, specifically, the Vehicle Emergency Data Set (VEDS) rather than
   the eCall Minimum Set of Data (MSD).  This document is an extension
   of the eCall document, with the primary differences being that this
   document makes the MSD data set optional and VEDS mandatory, and adds
   attribute values to the eCall metadata/control object to permit
   greater functionality.  This document registers a new INFO package
   (identical to that registered for eCall but with the addition of the
   VEDS MIME type).  This document also describes legacy (circuit-
   switched) ACN systems and their migration to next-generation
   emergency calling, to provide background information and context.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sun Sep 25 20:23:35 2016
Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959FC12B064 for <ecrit@ietfa.amsl.com>; Sun, 25 Sep 2016 20:23:33 -0700 (PDT)
X-Quarantine-ID: <0eAud2csMD3i>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -4.216
X-Spam-Level: 
X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eAud2csMD3i for <ecrit@ietfa.amsl.com>; Sun, 25 Sep 2016 20:23:32 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2F88012B040; Sun, 25 Sep 2016 20:23:32 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 25 Sep 2016 20:23:31 -0700
Mime-Version: 1.0
Message-Id: <p06240602d40e451cdac4@[99.111.97.136]>
In-Reply-To: <p06240602d40cefd4dd4c@[99.111.97.136]>
References: <147460051915.22446.3905020998297020767.idtracker@ietfa.amsl.com> <147460071860.22446.2297178978097588073.idtracker@ietfa.amsl.com> <p06240602d40cefd4dd4c@[99.111.97.136]>
X-Mailer: Eudora for Mac OS X
Date: Sun, 25 Sep 2016 20:23:30 -0700
To: ecrit@ietf.org
From: Randall Gellens <rg+ietf@randy.pensive.org>
Cc: ecrit@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/1oymu4jL_3Oflr-3nkSvhWSLmI0>
Subject: Re: [Ecrit] draft-ietf-ecrit-ecall-13 & draft-ietf-ecrit-car-crash-11
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2016 03:23:33 -0000

I updated car-crash to -12, to add a sentence to the Terminology 
section that clarifies that "IVS" can mean either an IVS or TSP when 
discussing signaling.


At 8:11 PM -0700 9/24/16, Randall Gellens wrote:

>  Hi ECRIT,
>
>  The versions draft-ietf-ecrit-ecall-13 & 
> draft-ietf-ecrit-car-crash-11 address all comments.
>
>  --Randy
>
>  _______________________________________________
>  Ecrit mailing list
>  Ecrit@ietf.org
>  https://www.ietf.org/mailman/listinfo/ecrit


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Never ask two questions in a business letter.  The reply will
discuss the one you are least interested in and say nothing about
the other.


From nobody Fri Sep 30 13:47:44 2016
Return-Path: <session_request_developers@ietf.org>
X-Original-To: ecrit@ietf.org
Delivered-To: ecrit@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8584F127A90; Fri, 30 Sep 2016 13:47:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Meeting Session Request Tool\"" <session_request_developers@ietf.org>
To: <session-request@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.34.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147526846250.20385.3738451513698325052.idtracker@ietfa.amsl.com>
Date: Fri, 30 Sep 2016 13:47:42 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/RfmEcTGYMHGJfKPBIY65KsdTRGE>
Cc: allison.mankin@gmail.com, ecrit@ietf.org, ecrit-chairs@ietf.org
Subject: [Ecrit] ecrit - Not having a session at IETF 97
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2016 20:47:42 -0000

Allison Mankin, a chair of the ecrit working group, indicated that the ecrit working group does not plan to hold a session at IETF 97.

This message was generated and sent by the IETF Meeting Session Request Tool.



From nobody Fri Sep 30 14:07:43 2016
Return-Path: <allison.mankin@gmail.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A8A128E19 for <ecrit@ietfa.amsl.com>; Fri, 30 Sep 2016 14:07:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-gGyzcgBXTb for <ecrit@ietfa.amsl.com>; Fri, 30 Sep 2016 14:07:39 -0700 (PDT)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0C35128874 for <ecrit@ietf.org>; Fri, 30 Sep 2016 14:07:38 -0700 (PDT)
Received: by mail-vk0-x232.google.com with SMTP id 192so114944051vkl.2 for <ecrit@ietf.org>; Fri, 30 Sep 2016 14:07:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to; bh=CHck+ATc5sKd101CnaEQM54G6dKWmV6tV6t4ickMB0w=; b=YELZfpOhNw3zanhiiJV81WiXjHp5gEWCLbZjrlxS61Eld9UeHsvHzaQ9o6qK22QeTT jG+eIHpoKvgJfkVTWtmLG8HORpmsVHots97+0Z90FRGrX+RAabn8HvSxwJ4y5ojooRE4 ZGo+X7md58D6E/fszGO0ldtlV0nou6wU8qDllxxkQVNsuIbShph1cNcj22wMW7EV70GW jfIDpVT8DLKMmuUq8zj5/yv/plXjq/P2GtBl30pmAkkDIDSNjp+I1BeYvmRee70Smq4n /Sv3gQ23qCCDq/FSUowYgvftOPporClxP42St1lJUj7OTYc35HJ/HS4sRxJG/nNJMlHU 26HQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CHck+ATc5sKd101CnaEQM54G6dKWmV6tV6t4ickMB0w=; b=NmVkSBQseq7pBb92GOIdNELtMDb86+hqmQJa8iGPXVPRztQjpJ4xbHPXc2QfFfdJ0x UNPuOS+DcfcfQn4hFiAlOSHtSzliK4xP30B8KE1CWDcLX76GnFaSQoWUdqeKE36jdAz3 MoNoVe+5ncqthR0rWsgwIi31aUgrNpysCn39tV4mQHrzB6LnXL0HYqgKWsqaZgAL4tYB K74W8Q3gQS7m84YOE5pUxfyedM9ZrVAYPhbhcZDlZp2b+8322JLMwW3fE2MvJ1pyXBNc RK9RX43nbdGAWIY8wPbxs8oxATmYoVmn2ay/A1OudxWu1wIbG5f7EJqh7aPsuSy8QbFH 9FoA==
X-Gm-Message-State: AA6/9RnKmmquMhzko01glgZwgBvmRbqVwqoeFHwh8CxdIRS6hfRIrfCvGOlFs7ePdmvTWNvQZ180pyj+wZvExQ==
X-Received: by 10.31.150.201 with SMTP id y192mr6008238vkd.74.1475269657740; Fri, 30 Sep 2016 14:07:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.34.48 with HTTP; Fri, 30 Sep 2016 14:07:37 -0700 (PDT)
From: Allison Mankin <allison.mankin@gmail.com>
Date: Fri, 30 Sep 2016 17:07:37 -0400
Message-ID: <CAP8yD=s0cD56xLQiGQAjkAQS+RVBEA7vLM7kW6m_i33uXnYj8g@mail.gmail.com>
To: ecrit@ietf.org
Content-Type: multipart/alternative; boundary=001a1141f50ee5ce4a053dbffb3a
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/mZpAHWBo1zQAeGbqPhcdDU8WgGQ>
Subject: [Ecrit] Fwd: ecrit - Not having a session at IETF 97
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2016 21:07:41 -0000

--001a1141f50ee5ce4a053dbffb3a
Content-Type: text/plain; charset=UTF-8

Hi, folks

We marked the WG as not meeting at IETF 97 - the ART ADs specifically asked
the groups not meeting say so, and the deadline was today.

Roger and I talked about this offline a couple of times, and he indicated
that there was a consensus at IETF 96 (before my time :-) to not meet
again, and to finish the five drafts by email.  We're progressing on that.

We also had consensus not to close the group, but to go on a hiatus after
the drafts are done.

See you online, and also in the hallways and in other WGs, at IETF 97.

Allison


---------- Forwarded message ----------
From: "IETF Meeting Session Request Tool" <
session_request_developers@ietf.org>
Date: 30 September 2016 at 16:47
Subject: ecrit - Not having a session at IETF 97
To: session-request@ietf.org
Cc: allison.mankin@gmail.com, alissa@cooperw.in, ecrit-chairs@ietf.org,
ecrit@ietf.org




Allison Mankin, a chair of the ecrit working group, indicated that the
ecrit working group does not plan to hold a session at IETF 97.

This message was generated and sent by the IETF Meeting Session Request
Tool.

--001a1141f50ee5ce4a053dbffb3a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif">Hi, folks<br><br></div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif">We marked the WG as not meeti=
ng at IETF 97 - the ART ADs specifically asked the groups not meeting say s=
o, and the deadline was today.=C2=A0 <br><br></div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif">Roger and I talked ab=
out this offline a couple of times, and he indicated that there was a conse=
nsus at IETF 96 (before my time :-) to not meet again, and to finish the fi=
ve drafts by email.=C2=A0 We&#39;re progressing on that.<br><br></div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif">We=
 also had consensus not to close the group, but to go on a hiatus after the=
 drafts are done. <br><br></div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif">See you online, and also in the hallways=
 and in other WGs, at IETF 97.<br><br></div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif">Allison <br><br><br></div><d=
iv class=3D"gmail_quote">---------- Forwarded message ----------<br>From: <=
b class=3D"gmail_sendername">&quot;IETF Meeting Session Request Tool&quot;<=
/b> <span dir=3D"ltr">&lt;<a href=3D"mailto:session_request_developers@ietf=
.org">session_request_developers@ietf.org</a>&gt;</span><br>Date: 30 Septem=
ber 2016 at 16:47<br>Subject: ecrit - Not having a session at IETF 97<br>To=
: <a href=3D"mailto:session-request@ietf.org">session-request@ietf.org</a><=
br>Cc: <a href=3D"mailto:allison.mankin@gmail.com">allison.mankin@gmail.com=
</a>, <a href=3D"mailto:alissa@cooperw.in">alissa@cooperw.in</a>, <a href=
=3D"mailto:ecrit-chairs@ietf.org">ecrit-chairs@ietf.org</a>, <a href=3D"mai=
lto:ecrit@ietf.org">ecrit@ietf.org</a><br><br><br><br>
<br>
Allison Mankin, a chair of the ecrit working group, indicated that the ecri=
t working group does not plan to hold a session at IETF 97.<br>
<br>
This message was generated and sent by the IETF Meeting Session Request Too=
l.<br>
<br>
<br>
</div><br></div>

--001a1141f50ee5ce4a053dbffb3a--


From nobody Fri Sep 30 16:29:34 2016
Return-Path: <ietf-secretariat-reply@ietf.org>
X-Original-To: ecrit@ietf.org
Delivered-To: ecrit@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8620B12B00D; Fri, 30 Sep 2016 16:29:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
To: <draft-ecrit-lost-planned-changes@ietf.org>, <ecrit-chairs@ietf.org>, <ecrit@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.34.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147527817250.20484.8964585062687841481.idtracker@ietfa.amsl.com>
Date: Fri, 30 Sep 2016 16:29:32 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/HP_MWKRRdhWU2ZggSebp5R1Bfmg>
Subject: [Ecrit] The ECRIT WG has placed draft-ecrit-lost-planned-changes in state "Adopted by a WG"
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2016 23:29:32 -0000

The ECRIT WG has placed draft-ecrit-lost-planned-changes in state 
Adopted by a WG (entered by Allison Mankin)

The document is available at
https://datatracker.ietf.org/doc/draft-ecrit-lost-planned-changes/


Comment:
Recorded support for adoption at IETF in BA, followed by mailing list
thread with a good number of substantive supporters.  Start of thread:
https://www.ietf.org/mail-archive/web/ecrit/current/msg09531.html


From nobody Fri Sep 30 16:31:39 2016
Return-Path: <allison.mankin@gmail.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE63A1200DF for <ecrit@ietfa.amsl.com>; Fri, 30 Sep 2016 16:31:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ln9_4DlyG9su for <ecrit@ietfa.amsl.com>; Fri, 30 Sep 2016 16:31:35 -0700 (PDT)
Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A527012B151 for <ecrit@ietf.org>; Fri, 30 Sep 2016 16:31:35 -0700 (PDT)
Received: by mail-ua0-x22b.google.com with SMTP id n13so107446236uaa.3 for <ecrit@ietf.org>; Fri, 30 Sep 2016 16:31:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to;  bh=kXM9kZrkDHHTYHse/mU5fHRZRjH5tpYXzlB+JSYNaBc=; b=pgirja23748XZseYarhpbw3eeQCh7NpraCaK1FDlNYkZqYq2vM3d+r230j15m+tAN0 r1smQsorpI5632DVkPn+7TtNxeMHG86r4RfdtihpbnGKBXSN+uqP1W58BY0yITB9SGQQ 6lTsnDSFYFylhActNXtHdyTwyZvptMH7U3kfi3EM4dm8S2IGAK0H0sH6msUntdi6STYA 8Z6HZlqxXoudnbv6BxkCOJzbGhYZJuHAy3MKrJYpqwBoydwzxjdgzH+S8e9GktEf4AZO 0huBCtBpo/l1wRoE8epN/e9bHCNY+FU2W7KoyW8x8iJfgVJbSgi9EtojpcPZp/1JnmTB CJ4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=kXM9kZrkDHHTYHse/mU5fHRZRjH5tpYXzlB+JSYNaBc=; b=TadsTZMcG9D5fdML7AcTtVpAeeCHLfAG38p35hCkqPqo8emu5h1vBx5dHTQmIwpdzp sXMi1uY2FoRmhPwKbRH6yVVyZrvgL3rBKT6h7Pm9xHkZkS3+jax1Bw1F3ndupQnUPTlj C+SB4Qv/YN/y6WZ0+WjJ2ryaKtVhjnJdKGJUvnT7z9f7WWi5b0rhMr5tgElnR7WXG+FE +fMkLu0Zc9ASr2CxmOg7u9eVp0OGcwHSBjjSF1Ppo0SbWDR2YRyn5YbZnBCTeg7cMeB2 bK/ewwE/7wEznEmxb6aHV3LbioLZbc412u4r9PBFSfp1C+shAlW4fH6FDG258/a9NlBm JJUQ==
X-Gm-Message-State: AA6/9RkrH5V/JtHKJc/diS7T2WLn9pVm76xzWKPCv8StxxU1roFOCMx+3DvUYJGIuKjsiMg27Y613HqTnYwZGg==
X-Received: by 10.159.49.83 with SMTP id n19mr7251208uab.113.1475278294457; Fri, 30 Sep 2016 16:31:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.34.48 with HTTP; Fri, 30 Sep 2016 16:31:33 -0700 (PDT)
In-Reply-To: <147527817250.20484.8964585062687841481.idtracker@ietfa.amsl.com>
References: <147527817250.20484.8964585062687841481.idtracker@ietfa.amsl.com>
From: Allison Mankin <allison.mankin@gmail.com>
Date: Fri, 30 Sep 2016 19:31:33 -0400
Message-ID: <CAP8yD=shtMOC33Ri4C2ZoH7ZHof-+id9h1xFTnerS6WaThepFg@mail.gmail.com>
To: ecrit@ietf.org
Content-Type: multipart/alternative; boundary=f403045dce8aafa5f6053dc1febb
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/kR9uHw7EdLBmOjchlbb3z2FENus>
Subject: [Ecrit] Fwd: The ECRIT WG has placed draft-ecrit-lost-planned-changes in state "Adopted by a WG"
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2016 23:31:38 -0000

--f403045dce8aafa5f6053dc1febb
Content-Type: text/plain; charset=UTF-8

Hi, folks,

Some housekeeping - we're getting ready to request IETF LC for this and
this state change had fallen through the cracks.

Allison

---------- Forwarded message ----------
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
Date: 30 September 2016 at 19:29
Subject: The ECRIT WG has placed draft-ecrit-lost-planned-changes in state
"Adopted by a WG"
To: draft-ecrit-lost-planned-changes@ietf.org, ecrit-chairs@ietf.org,
ecrit@ietf.org



The ECRIT WG has placed draft-ecrit-lost-planned-changes in state
Adopted by a WG (entered by Allison Mankin)

The document is available at
https://datatracker.ietf.org/doc/draft-ecrit-lost-planned-changes/


Comment:
Recorded support for adoption at IETF in BA, followed by mailing list
thread with a good number of substantive supporters.  Start of thread:
https://www.ietf.org/mail-archive/web/ecrit/current/msg09531.html

--f403045dce8aafa5f6053dc1febb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif">Hi, folks,<br><br></div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif">Some housekeeping - we&#39;r=
e getting ready to request IETF LC for this and this state change had falle=
n through the cracks.<br><br></div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif">Allison<br><br></div><div class=3D"gm=
ail_quote">---------- Forwarded message ----------<br>From: <b class=3D"gma=
il_sendername">IETF Secretariat</b> <span dir=3D"ltr">&lt;<a href=3D"mailto=
:ietf-secretariat-reply@ietf.org">ietf-secretariat-reply@ietf.org</a>&gt;</=
span><br>Date: 30 September 2016 at 19:29<br>Subject: The ECRIT WG has plac=
ed draft-ecrit-lost-planned-changes in state &quot;Adopted by a WG&quot;<br=
>To: <a href=3D"mailto:draft-ecrit-lost-planned-changes@ietf.org">draft-ecr=
it-lost-planned-changes@ietf.org</a>, <a href=3D"mailto:ecrit-chairs@ietf.o=
rg">ecrit-chairs@ietf.org</a>, <a href=3D"mailto:ecrit@ietf.org">ecrit@ietf=
.org</a><br><br><br><br>
The ECRIT WG has placed draft-ecrit-lost-planned-<wbr>changes in state<br>
Adopted by a WG (entered by Allison Mankin)<br>
<br>
The document is available at<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ecrit-lost-planned-change=
s/" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/<wbr>=
doc/draft-ecrit-lost-planned-<wbr>changes/</a><br>
<br>
<br>
Comment:<br>
Recorded support for adoption at IETF in BA, followed by mailing list<br>
thread with a good number of substantive supporters.=C2=A0 Start of thread:=
<br>
<a href=3D"https://www.ietf.org/mail-archive/web/ecrit/current/msg09531.htm=
l" rel=3D"noreferrer" target=3D"_blank">https://www.ietf.org/mail-<wbr>arch=
ive/web/ecrit/current/<wbr>msg09531.html</a><br>
</div><br></div>

--f403045dce8aafa5f6053dc1febb--