From rg+ietf@qualcomm.com  Fri Nov  1 19:36:30 2013
Return-Path: <rg+ietf@qualcomm.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 A571811E8152 for <ecrit@ietfa.amsl.com>; Fri,  1 Nov 2013 19:36:30 -0700 (PDT)
X-Quarantine-ID: <PgbrPmUQqYeP>
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: -104.227
X-Spam-Level: 
X-Spam-Status: No, score=-104.227 tagged_above=-999 required=5 tests=[AWL=-1.628, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgbrPmUQqYeP for <ecrit@ietfa.amsl.com>; Fri,  1 Nov 2013 19:36:25 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 7240111E810B for <ecrit@ietf.org>; Fri,  1 Nov 2013 19:36:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1383359766; x=1414895766; h=x-ojodefuego:message-id:in-reply-to:references:x-mailer: date:to:from:subject:content-type; bh=u4pAT5NsBt20hPQD1FSDeGKVWlbjTeRtmD6J7JujvB4=; b=X2A+TSUHk22DnvR1dt3NAjMVRp7xNFqP+Y7ePYAxF4TDNVL2hHMqQP06 OELgcmRUK+OcctmjKIPx9fkIbK2B+gc7NQj0kp0hE139QEHmkSgNSXQwy sYreIqZHIjpNBU5CiFfVW44NLoZ0CU3HT1lX9O9huNoI5v50KFU6HGS5n 4=;
X-IronPort-AV: E=McAfee;i="5400,1158,7246"; a="54968371"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP; 01 Nov 2013 19:36:04 -0700
X-IronPort-AV: E=McAfee;i="5400,1158,7246"; a="566840368"
Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2013 19:36:04 -0700
Received: from Ironmsg04-R.qualcomm.com (ironmsg04-R.qualcomm.com [172.30.46.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id rA22a4hn029978;  Fri, 1 Nov 2013 19:36:04 -0700
X-IronPort-AV: E=McAfee;i="5400,1158,7246"; a="632008245"
X-ojodefuego: yes
Received: from unknown (HELO [99.111.97.136]) ([10.64.210.111]) by Ironmsg04-R.qualcomm.com with ESMTP; 01 Nov 2013 19:35:51 -0700
Mime-Version: 1.0
Message-Id: <p06240600ce9a0edadc51@[99.111.97.136]>
In-Reply-To: <525E5B92.7040106@gmx.net>
References: <2D09D61DDFA73D4C884805CC7865E61130317C8F@GAALPA1MSGUSR9L.ITServices.s bc.com> <525E5B92.7040106@gmx.net>
X-Mailer: Eudora for Mac OS X
Date: Fri, 1 Nov 2013 19:35:25 -0700
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, "STARK, BARBARA H" <bs7652@att.com>, "ecrit@ietf.org" <ecrit@ietf.org>
From: Randall Gellens <rg+ietf@qualcomm.com>
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
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10: comments on data provider elements
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 02 Nov 2013 02:36:30 -0000

At 11:25 AM +0200 10/16/13, Hannes Tschofenig wrote:

>     Data Element:  Data Provider String

>     How Used by Call Taker:  Allows the call taker to interpret the data
>        in this structure.  The source of the information often influences
>        how the information is used, believed or verified.

The string isn't verified in any way, is it?  E.g., someone could 
operate his/her own LIS and set the string to the name of of any 
major network or service provider.


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I don't hate Microsoft.  I never have hated Microsoft.
Love the sinner, hate the sin.       --Martin Frankel

From rg+ietf@qualcomm.com  Fri Nov  1 19:36:33 2013
Return-Path: <rg+ietf@qualcomm.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 272CE21E809C for <ecrit@ietfa.amsl.com>; Fri,  1 Nov 2013 19:36:33 -0700 (PDT)
X-Quarantine-ID: <x-kCTjzFYkaP>
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: -103.684
X-Spam-Level: 
X-Spam-Status: No, score=-103.684 tagged_above=-999 required=5 tests=[AWL=-1.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-kCTjzFYkaP for <ecrit@ietfa.amsl.com>; Fri,  1 Nov 2013 19:36:28 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id CFE0E11E8171 for <ecrit@ietf.org>; Fri,  1 Nov 2013 19:36:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1383359788; x=1414895788; h=x-ojodefuego:message-id:in-reply-to:references:x-mailer: date:to:from:subject:content-type; bh=MmEdaSNXOAG3erkqRTFhETROWp66IYBiCk2IMyaTHX8=; b=p2qdAOub8HsmSTuSUa0g3+6GFAoqwaS9ylUS2JiLWSH6hOB5c1Baa6dR VRhbANS7MMO64G3Hs73Ll+AGlV2nhgm+ug0JPgNinCqh1rqghZpcwWKMk 6DrzG9gfnfHBCd2AIiX+upXKiBif5a+y3FAX8Le0lzT6CwdTjRpfWAFZm A=;
X-IronPort-AV: E=McAfee;i="5400,1158,7246"; a="54968375"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP; 01 Nov 2013 19:36:28 -0700
X-IronPort-AV: E=McAfee;i="5400,1158,7246"; a="566840509"
Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2013 19:36:28 -0700
Received: from Ironmsg04-R.qualcomm.com (ironmsg04-R.qualcomm.com [172.30.46.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id rA22aSaN029983;  Fri, 1 Nov 2013 19:36:28 -0700
X-IronPort-AV: E=McAfee;i="5400,1158,7246"; a="632008267"
X-ojodefuego: yes
Received: from unknown (HELO [99.111.97.136]) ([10.64.210.111]) by Ironmsg04-R.qualcomm.com with ESMTP; 01 Nov 2013 19:36:07 -0700
Mime-Version: 1.0
Message-Id: <p06240601ce9a114b6eb7@[99.111.97.136]>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4BFFBE@ESESSMB209.ericsson.se>
References: <20131016091416.32193.78065.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1C4BFFBE@ESESSMB209.ericsson.se>
X-Mailer: Eudora for Mac OS X
Date: Fri, 1 Nov 2013 19:35:25 -0700
To: Christer Holmberg <christer.holmberg@ericsson.com>, "ecrit@ietf.org" <ecrit@ietf.org>
From: Randall Gellens <rg+ietf@qualcomm.com>
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
Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-13.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 02 Nov 2013 02:36:33 -0000

At 10:09 AM +0000 10/16/13, Christer Holmberg wrote:

>  Q2:	Question on possible conflict between language feature tag 
> and data provider language, defined in section 3.1.6
>  E-mail:	http://www.ietf.org/mail-archive/web/ecrit/current/msg08642.html

My understanding is that these have different semantics: the SIP 
language indicates the language to be used for SIP messages (which I 
would expect to be the language of the end user's UI), while the data 
provider language indicates the language used by the data provider 
(e.g., if the PSAP calls the entity, which language is expected).


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Laughter is the closest distance between two people.
                                     --Victor Borge

From rg+ietf@qualcomm.com  Fri Nov  1 19:37:50 2013
Return-Path: <rg+ietf@qualcomm.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 E198B11E810B for <ecrit@ietfa.amsl.com>; Fri,  1 Nov 2013 19:37:50 -0700 (PDT)
X-Quarantine-ID: <RbJPjBsmtKjr>
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: -102.684
X-Spam-Level: 
X-Spam-Status: No, score=-102.684 tagged_above=-999 required=5 tests=[AWL=-1.543, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbJPjBsmtKjr for <ecrit@ietfa.amsl.com>; Fri,  1 Nov 2013 19:37:46 -0700 (PDT)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 865FA11E8171 for <ecrit@ietf.org>; Fri,  1 Nov 2013 19:37:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1383359864; x=1414895864; h=x-ojodefuego:message-id:in-reply-to:references:x-mailer: date:to:from:subject:cc:content-type: content-transfer-encoding; bh=Q5py2Z2Ztf5RX5aNZB4Fl2YP+3TKNEFmIkA99aKASsA=; b=CqetIzSjCVntfQVrSbVEhdcC4I/7cKgVqU6LlmkLAwS2+Z//Mxq8iNwY PCmnsSGxnvFE4uxEOCaoAWdGPUt64rIK+9CFmqDDtTO6g90uhZO8ecO/Q W3Xgx2QpKgXY5VCux6EdwazPMC6pLfW7IA6g/LBor8vqWJOIJ3gp8uu4W k=;
X-IronPort-AV: E=McAfee;i="5400,1158,7246"; a="54870152"
Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by sabertooth01.qualcomm.com with ESMTP; 01 Nov 2013 19:37:44 -0700
X-IronPort-AV: E=McAfee;i="5400,1158,7246"; a="147552721"
Received: from plus.qualcomm.com ([10.52.255.8]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2013 19:37:43 -0700
Received: from Ironmsg04-R.qualcomm.com (ironmsg04-R.qualcomm.com [172.30.46.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id rA22bhxq030001;  Fri, 1 Nov 2013 19:37:43 -0700
X-IronPort-AV: E=McAfee;i="5400,1158,7246"; a="632008301"
X-ojodefuego: yes
Received: from unknown (HELO [99.111.97.136]) ([10.64.210.111]) by Ironmsg04-R.qualcomm.com with ESMTP; 01 Nov 2013 19:36:46 -0700
Mime-Version: 1.0
Message-Id: <p06240602ce9a13d807ee@[99.111.97.136]>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4EBC2B@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C41E812@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C422BC7@ESESSMB209.ericsson.se>, <CAOPrzE3XQGhXgH_zPpNDeLBrPb4hRUp2JefV2s9TqW1Ku0=RSA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C422DB7@ESESSMB209.ericsson.se> <FBD5AAFFD0978846BF6D3FAB4C892ACC3EDF01@SEA-EXMB-1.telecomsys.com>, <52669D95.8030501@gmx.net> <7594FB04B1934943A5C02806D1A2204B1C4EBC2B@ESESSMB209.ericsson.se>
X-Mailer: Eudora for Mac OS X
Date: Fri, 1 Nov 2013 19:35:25 -0700
To: Christer Holmberg <christer.holmberg@ericsson.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, Roger Marshall	<RMarshall@telecomsys.com>, Brian Rosen <br@brianrosen.net>
From: Randall Gellens <rg+ietf@qualcomm.com>
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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
Cc: "ecrit_ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of the Contact URI, defined in section 3.1.5
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 02 Nov 2013 02:37:51 -0000

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type=3D"text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [Ecrit] draft-ietf-ecrit-additional-data-11:
Question</title></head><body>
<div>Do we really need to say MUST NOT?&nbsp; Would it be sufficient
to describe why the URL is not appropriate?&nbsp; E.g., &quot;Note
that this contact information is not intended for nor is it suitable
for a callback by a PSAP....&quot;</div>
<div><br></div>
<div>At 6:43 PM +0000 10/22/13, Christer Holmberg wrote:</div>
<div><br></div>
<blockquote type=3D"cite" cite>Content-Language: en-US<br>
Content-Type: multipart/alternative;<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;
</x-tab
>boundary=3D&quot;_000_7594FB04B1934943A5C02806D1A2204B1C4EBC2BESESSMB2<span
></span>09erics_&quot;<br>
</blockquote>
<blockquote type=3D"cite" cite>Hi,<br>
</blockquote>
<blockquote type=3D"cite" cite>&nbsp;<br>
</blockquote>
<blockquote type=3D"cite" cite>I would&nbsp;suggest that the contact
information MUST NOT be used by the PSAP for callbacks, and also say
that the reason is because the contact information may not be
associated with the user or the device that made the emergency call.
No need to mention the Priority header field, simply refer to the
psap-callback draft.<br>
</blockquote>
<blockquote type=3D"cite" cite>&nbsp;<br>
</blockquote>
<blockquote type=3D"cite" cite>Something like:<br>
</blockquote>
<blockquote type=3D"cite" cite>&nbsp;<br>
</blockquote>
<blockquote type=3D"cite" cite>&nbsp;&nbsp;&nbsp;&nbsp;&quot;Note that
this contact information&nbsp;MUST NOT be&nbsp;used by PSAPs for
callbacks,<br>
</blockquote>
<blockquote type=3D"cite" cite>&nbsp;&nbsp;&nbsp;&nbsp;as described in
[I-D.ietf-ecrit-psap-callback], as the contact information might<br>
</blockquote>
<blockquote type=3D"cite" cite>&nbsp;&nbsp;&nbsp;&nbsp;not be associated
with the user or device that made the emergency call.&quot;<br>
</blockquote>
<blockquote type=3D"cite" cite>&nbsp;<br>
</blockquote>
<blockquote type=3D"cite" cite>Regards,<br>
</blockquote>
<blockquote type=3D"cite" cite>&nbsp;<br>
</blockquote>
<blockquote type=3D"cite" cite>Christer<br>
</blockquote>
<blockquote type=3D"cite" cite>&nbsp;<br>
</blockquote>
<blockquote type=3D"cite" cite>&nbsp;<br>
</blockquote>
<blockquote type=3D"cite" cite>
<hr></blockquote>
<blockquote type=3D"cite" cite><font face=3D"Tahoma"
color=3D"#000000"><b>From:</b> Hannes Tschofenig
[hannes.tschofenig@gmx.net]<br>
<b>Sent:</b> Tuesday, 22 October 2013 6:45 PM<br>
<b>To:</b> Roger Marshall; Christer Holmberg; Brian Rosen<br>
<b>Cc:</b> ecrit_ietf.org<br>
<b>Subject:</b> Re: [Ecrit] draft-ietf-ecrit-additional-data-11:
Question on scope of the Contact URI, defined in section
3.1.5</font><br>
<font face=3D"Tahoma" color=3D"#000000"></font></blockquote>
<blockquote type=3D"cite" cite>Hi Christer,<br>
<br>
as discussed in this email thread I added text for clarification:<br>
<br>
----<br>
<br>
3.1.5.&nbsp; Data Provider Contact URI<br>
<br>
&nbsp;&nbsp;&nbsp; Data Element:&nbsp; Data Provider Contact URI<br>
<br>
&nbsp;&nbsp;&nbsp; Use:&nbsp; Required<br>
<br>
&nbsp;&nbsp;&nbsp; XML Element:&nbsp; &lt;ContactURI&gt;<br>
<br>
&nbsp;&nbsp;&nbsp; Description:&nbsp; When provided by a service
provider or an access<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; provider, this information MUST
be a URI to a 24/7 support<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; organization tasked to provide
PSAP support for this emergency<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; call.&nbsp; If the call is from a
device, this would reflect the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contact information of the owner
of the device.&nbsp; If a telephone<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; number is the contact address
then it MUST be tel URI.&nbsp; If it is<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; provided as a SIP URI then it
MUST be in the form of<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sip:telephonenumber@serviceprovider:user=3Dphone.&nbsp; Note that
this<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contact information is not used
by PSAPs for callbacks using a SIP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Priority header field with the
value set to &quot;psap- callback&quot;, as<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; described in
[I-D.ietf-ecrit-psap-callback].<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
----<br>
<br>
<br>
Do you think that I managed to capture your concern?<br>
<br>
Ciao<br>
Hannes<br>
<br>
<br>
On 08/26/2013 10:33 PM, Roger Marshall wrote:<br>
&gt; I agree with Christer=D5s suggestion to add caution text.<br>
&gt;<br>
&gt; -roger.<br>
&gt;<br>
&gt; *From:*ecrit-bounces@ietf.org [<a
href=3D"mailto:ecrit-bounces@ietf.org">mailto:ecrit-bounces@ietf.org</a
>] *On Behalf<br>
&gt; Of *Christer Holmberg<br>
&gt; *Sent:* Thursday, August 08, 2013 9:44 PM<br>
&gt; *To:* Brian Rosen<br>
&gt; *Cc:* ecrit_ietf.org<br>
&gt; *Subject:* Re: [Ecrit] draft-ietf-ecrit-additional-data-11:
Question on<br>
&gt; scope of the Contact URI, defined in section 3.1.5<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; If the PSAP is not supposed to use the field when/if making a
callback,<br>
&gt; I think we shall explicitly state that in the document, and/or
in<br>
&gt; general say that the field must not be used for calls that are
expected<br>
&gt; to be given priority/special handling, and give callback as an
example.<br>
&gt;<br>
&gt; Regards,<br>
&gt;<br>
&gt; Christer<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Sent from */Windows/* using *TouchDown*(<a
href=3D"http:///">www.nitrodesk.com<br>
&gt; &lt;</a><a
href=3D"http://www.nitrodesk.com/">http://www.nitrodesk.com</a>&gt;)<br>
&gt;<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; *From:* Brian Rosen [br@brianrosen.net]<br>
&gt; *To:* Christer Holmberg [christer.holmberg@ericsson.com]<br>
&gt; *CC:* ecrit_ietf.org [ecrit@ietf.org]<br>
&gt; *Subject:* Re: [Ecrit] draft-ietf-ecrit-additional-data-11:
Question on<br>
&gt; scope of the Contact URI, defined in section 3.1.5<br>
&gt;<br>
&gt; The Contact is how the PSAP contacts the service provider to get
help</blockquote>
<blockquote type=3D"cite" cite>&gt; from the SP.<br>
&gt;<br>
&gt; It's not a &quot;call back&quot; in the sense of an emergency
call (the network<br>
&gt; doesn't treat it differently than a normal call), at least as far
as I<br>
&gt; have considered it.&nbsp; I suppose it might be nice to know that
it's<br>
&gt; important, but I don't think that is worth any big new
mechanism.<br>
&gt;<br>
&gt; Brian<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Thursday, August 8, 2013, Christer Holmberg wrote:<br>
&gt;<br>
&gt; I haven't seen any reply to this. Brian, do you have any
opinion?<br>
&gt;<br>
&gt; Regards,<br>
&gt;<br>
&gt; Christer<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Sent from */Windows/* using *TouchDown* (<a
href=3D"http:///">www.nitrodesk.com<br>
&gt; &lt;</a><a
href=3D"http://www.nitrodesk.com/">http://www.nitrodesk.com</a>&gt;)<br>
&gt;<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; *From:* Christer Holmberg [christer.holmberg@ericsson.com]<br>
&gt; *To:* ecrit@ietf.org [ecrit@ietf.org]<br>
&gt; *Subject:* [Ecrit] draft-ietf-ecrit-additional-data-11: Question
on<br>
&gt; scope of the Contact URI, defined in section 3.1.5<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; A question on the scope of the Contact URI, defined in section
3.1.5 of<br>
&gt; draft-ietf-ecrit-additional-data-11.txt.<br>
&gt;<br>
&gt; Is the Contact URI supposed by the PSAP when making
callbacks?<br>
&gt;<br>
&gt; If the value represents a =D2service provider=D3, should PSAP
callbacks also<br>
&gt; be made to the service provider?<br>
&gt;<br>
&gt; Regards,<br>
&gt;<br>
&gt; Christer<br>
&gt;<br>
&gt; CONFIDENTIALITY NOTICE: The information contained in this message
may be<br>
&gt; privileged and/or confidential. If you are not the intended
recipient,<br>
&gt; or responsible for delivering this message to the intended
recipient,<br>
&gt; any review, forwarding, dissemination, distribution or copying of
this<br>
&gt; communication or any attachment(s) is strictly prohibited. If you
have<br>
&gt; received this message in error, please notify the sender
immediately,<br>
&gt; and delete it and all attachments from your computer and
network.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Ecrit mailing list<br>
&gt; Ecrit@ietf.org<br>
&gt; <a
href=3D"https://www.ietf.org/mailman/listinfo/ecrit"
>https://www.ietf.org/mailman/listinfo/ecrit</a><br>
&gt;<br>
</blockquote>
<blockquote type=3D"cite" cite><br>
_______________________________________________<br>
Ecrit mailing list<br>
Ecrit@ietf.org<br>
https://www.ietf.org/mailman/listinfo/ecrit</blockquote>
<div><br></div>
<div><br></div>
<div><br></div>
<x-sigsep><pre>-- 
</pre></x-sigsep>
<div>Randall Gellens<br>
Opinions are personal;&nbsp;&nbsp;&nbsp; facts are
suspect;&nbsp;&nbsp;&nbsp; I speak for myself only<br>
-------------- Randomly selected tag: ---------------<br>
Blessed are the meek for they shall inhibit the earth.<br>
</div></body>
</html>

From rg+ietf@qualcomm.com  Fri Nov  1 19:39:11 2013
Return-Path: <rg+ietf@qualcomm.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 25B5011E8152 for <ecrit@ietfa.amsl.com>; Fri,  1 Nov 2013 19:39:11 -0700 (PDT)
X-Quarantine-ID: <ZXWQDJSbZcwN>
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: -103.104
X-Spam-Level: 
X-Spam-Status: No, score=-103.104 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXWQDJSbZcwN for <ecrit@ietfa.amsl.com>; Fri,  1 Nov 2013 19:39:06 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id AEAA811E8171 for <ecrit@ietf.org>; Fri,  1 Nov 2013 19:39:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1383359944; x=1414895944; h=x-ojodefuego:message-id:in-reply-to:references:x-mailer: date:to:from:subject:cc:content-type; bh=2ELv4+3i9XQLBS1goco0N7gE7+0yD80AvaUb/GJRjTM=; b=t1ish8CiIq94nQkDtjWj6qCE100RaxHAjxVuNSAkxIyxfymADkT36aUH N64jS77TSdki21GvXvVrPF50Tob4SnF5rVnOCts3FqdyX25CKZWYcRfpi Y8QAzDWgTz2SemjiMRscufySZY3jy7KwpN9yQol/v54cv/ts4ueYxGKVg E=;
X-IronPort-AV: E=McAfee;i="5400,1158,7246"; a="54968418"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP; 01 Nov 2013 19:39:04 -0700
X-IronPort-AV: E=McAfee;i="5400,1158,7246"; a="578094739"
Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2013 19:39:04 -0700
Received: from Ironmsg04-R.qualcomm.com (ironmsg04-R.qualcomm.com [172.30.46.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id rA22d4k1030009;  Fri, 1 Nov 2013 19:39:04 -0700
X-IronPort-AV: E=McAfee;i="5400,1158,7246"; a="632008512"
X-ojodefuego: yes
Received: from unknown (HELO [99.111.97.136]) ([10.64.210.111]) by Ironmsg04-R.qualcomm.com with ESMTP; 01 Nov 2013 19:38:01 -0700
Mime-Version: 1.0
Message-Id: <p06240603ce9a14d843e7@[99.111.97.136]>
In-Reply-To: <5267B9D9.2020102@gmx.net>
References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <CAOPrzE37Lx-qxCCmRJ5RJX29t7EVyFZkESAEnAK5wCSySJDodw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> <ADE693DC-F327-4093-B06E-D89F1FFCA9DD@gmail.com> <CAOPrzE2nvpbPmfi0BmY-+wo6vZStQKvdEz5uFqt+8vX306biZA@mail.gmail.com> <52669FC8.4060009@gmx.net> <6B55C801-3DB1-44C2-9F26-40420BD8B6B3@brianrosen.net> <638896AF-51FC-4AC9-B55F-A2A59C49DEC8@gmail.com> <835DBA5E-F02B-435E-AE67-04E157272254@brianrosen.net> <0B5A3BCE-B92A-477B-9A7D-922F3B13265B@gmail.com> <58E93B5A-495E-4BB3-9231-944E04460C77@brianrosen.net> <74690D52-E081-419B-8615-DB04ED55B7D2@gmail.com> <27D665B2-BDB4-4C05-A859-78D7DFACD397@brianrosen.net> <34694050-A1CE-492C-9F1C-00945C5E8FCD@gmail.com> <2949DC42-3D5B-4237-9F6A-BABE65A9E42A@brianrosen.net> <BC28EA87-48A1-4A4F-98AC-818C3EA7413C@gmail.com> <5267B9D9.2020102@gmx.net>
X-Mailer: Eudora for Mac OS X
Date: Fri, 1 Nov 2013 19:35:25 -0700
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, James Winterbottom <a.james.winterbottom@gmail.com>, Brian Rosen	<br@brianrosen.net>
From: Randall Gellens <rg+ietf@qualcomm.com>
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
Cc: ecrit <ecrit@ietf.org>
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding data
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 02 Nov 2013 02:39:11 -0000

At 1:58 PM +0200 10/23/13, Hannes Tschofenig wrote:

>  I just tried to create a longer example, as Christer requested, and 
> the current structure indeed has some limitations (as discussed in 
> this thread between James and Brian).
>
>  There are two approaches to solve the problem:
>
>  a) Introduce a hierarchical structure within the MIME bodies.
>
>  b) Link the data provider block with other blocks.
>
>  To me, it appears that option (b) is somewhat easier. All we have 
> to do is the following:
>
>  1) Add a new element to the ProviderInfo block (let's call it <reference>)
>  2) Add a new element to the other blocks (let's call it <id>)
>  3) Add a requirement that all blocks added by a data provider must 
> have the same value in <id>, which is then repeated in the 
> <reference> element.
>
>  Of course, we have an id already in the MIME structure (in the form 
> of a Content-ID). This would allow us to avoid defining the <id> in 
> the structures but we would instead use the <reference> element to 
> enumerate the content-ids. It does not exist in the XML. Is that a 
> problem? For the provided-by structure, for example, we do not 
> communite MIME structures but I suspect that the PIDF document 
> would come from a single data provider anyway?!

This mechanism works fine for blocks provided by value.  I am not 
sure if blocks provided by reference will always have a Contend-ID 
when fetched, but perhaps it's irrelevant because the domain of the 
URL might serve the purpose.



>
>  On 10/22/2013 11:28 PM, James Winterbottom wrote:
>>  I think this clarifies my problem with the current structure.
>>  The provider would only ever send this block by itself if it 
>> doesn't have anything other to send. This implies that it doesn't 
>> know what kind of provider it actually is which doesn't seem 
>> useful.
>>
>>
>>  On 23/10/2013, at 8:20 AM, Brian Rosen <br@brianrosen.net> wrote:
>>
>>>  Because you also need it as a stand alone when that's all the 
>>> provider sends, and if you think, as I do, that the average 
>>> report that is more than just the provider block will have two or 
>>> more blocks, it's repetitive.  You don't get anything out of 
>>> repeating every element of the provider block.  You only want to 
>>> know which provider sent it.
>>>
>>>  Brian
>>>  On Oct 22, 2013, at 5:14 PM, James Winterbottom 
>>> <a.james.winterbottom@gmail.com> wrote:
>>>
>>>>  Yes, and so?
>>>>  This is dead simple with schema and achieves the tie in a 
>>>> totally unambiguous way.
>>>>
>>>>  On 23/10/2013, at 8:07 AM, Brian Rosen <br@brianrosen.net> wrote:
>>>>
>>>>>  Because the provider info is itself a block.  Repeating it does nothing.
>>>>>
>>>>>  We would have to make the content of the provider block a 
>>>>> component of every other block.
>>>>>
>>>>>  Brian
>>>>>
>>>>>  On Oct 22, 2013, at 4:54 PM, James Winterbottom 
>>>>> <a.james.winterbottom@gmail.com> wrote:
>>>>>
>>>>>>  I am not sure that I understand why it is such a problem to 
>>>>>> have provider blocks repeated if a single provider provides 
>>>>>> more than one block of information. This addresses the MIME 
>>>>>> issue and the requirement to have some kind of chaining unique 
>>>>>> ID.
>>>>>>
>>>>>>  Cheers
>>>>>>  James
>>>>>>
>>>>>>  On 23/10/2013, at 7:51 AM, Brian Rosen <br@brianrosen.net> wrote:
>>>>>>
>>>>>>>  By "fixing" the data structure to be a series of blocks, each 
>>>>>>> with it's own MIME type and schema, you can't really group 
>>>>>>> them in useful ways.
>>>>>>>  When I did the original, a given set of data from one source 
>>>>>>> was one object, and you could have more than one such object 
>>>>>>> in the body, or more than one URI to an entire object in the 
>>>>>>> Call-Info.  When  we split it up into blocks, we lost the 
>>>>>>> ability to group.
>>>>>>>
>>>>>>>  We could try doing something with mime/multipart hierarchy. 
>>>>>>> I don't know what is possible.  I don't think requiring all 
>>>>>>> blocks from the same source to have a unique ID in them is 
>>>>>>> brittle.
>>>>>>>
>>>>>>>  Brian
>>>>>>>
>>>>>>>  On Oct 22, 2013, at 4:17 PM, James Winterbottom 
>>>>>>> <a.james.winterbottom@gmail.com> wrote:
>>>>>>>
>>>>>>>>  I think that that is more brittle.
>>>>>>>>  If the requirement is that the data provided be firmly 
>>>>>>>> linked to source then tie them together more tightly.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  Sent from my iPad
>>>>>>>>
>>>>>>>>  On 23/10/2013, at 6:21 AM, Brian Rosen <br@brianrosen.net> wrote:
>>>>>>>>
>>>>>>>>>  I would be inclined to have a "source" attribute in every 
>>>>>>>>> block, which could be matched.  It could contain any 
>>>>>>>>> globally unique string (such as a domain name) that labels 
>>>>>>>>> the source of each block.
>>>>>>>>>
>>>>>>>>>  Brian
>>>>>>>>>
>>>>>>>>>  On Oct 22, 2013, at 3:16 PM, James Winterbottom 
>>>>>>>>> <a.james.winterbottom@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>  One way to do that is through schema structure and constraints.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  Sent from my iPad
>>>>>>>>>>
>>>>>>>>>>  On 23/10/2013, at 5:30 AM, Brian Rosen <br@brianrosen.net> wrote:
>>>>>>>>>>
>>>>>>>>>>> I don't think this is sufficient.  I think there has to 
be a way to know which data provider which block.
>>>>>>>>>>>
>>>>>>>>>>> What you have is:
>>>>>>>>>>> SP A provided some info
>>>>>>>>>>> SP B provided some info
>>>>>>>>>>> Info X, don't know who provided it
>>>>>>>>>>> Info Y, don't know who provided it
>>>>>>>>>>>
>>>>>>>>>>> Brian
>>>>>>>>>>>
>>>>>>>>>>> On Oct 22, 2013, at 11:54 AM, Hannes Tschofenig 
<Hannes.Tschofenig@gmx.net> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Christer, Brian, James,
>>>>>>>>>>>>
>>>>>>>>>>>> I believe you guys raised a couple of issues, namely:
>>>>>>>>>>>>
>>>>>>>>>>>> * Could we provide more and better examples? We have a 
number of examples in the document but we do not illustrate more 
complex versions.
>>>>>>>>>>>>
>>>>>>>>>>>> I am thinking about how to add a longer example.
>>>>>>>>>>>>
>>>>>>>>>>>> * Did we double-check whether there are any constraints 
regarding the number of blocks a single data provider can add and 
whether there are problems when multiple data provider add 
information?
>>>>>>>>>>>>
>>>>>>>>>>>> My suggestion is obvious: we have to double-check 
whether we introduced a bug.
>>>>>>>>>>>>
>>>>>>>>>>>> * Do we always have information about the source of the 
data provider? Brian claimed that we have lost that feature over 
time. I double-checked it and there is indeed some fuzziness in the 
text. Here is the relevant part:
>>>>>>>>>>>>
>>>>>>>>>>>> ------
>>>>>>>>>>>>
>>>>>>>>>>>> 3.1.  Data Provider Information
>>>>>>>>>>>>
>>>>>>>>>>>> This block is intended to be provided by any service 
provider in the
>>>>>>>>>>>> path of the call or the access network provider.  It includes
>>>>>>>>>>>> identification and contact information.  This block SHOULD be
>>>>>>>>>>>> provided by every service provider in the call path, and by the
>>>>>>>>>>>> access network provider.  Devices MAY use this block to provide
>>>>>>>>>>>> identifying information.  The MIME subtype is "application/
>>>>>>>>>>>> emergencyCall.ProviderInfo+xml".  An access network 
provider SHOULD
>>>>>>>>>>>> provide this block either by value or by reference in 
the Provided-By
>>>>>>>>>>>> section of a PIDF-LO
>>>>>>>>>>>>
>>>>>>>>>>>> ------
>>>>>>>>>>>>
>>>>>>>>>>>> I believe I hear Brian saying that he wants to have the 
data provider block be added whenever data is added. I suggest the 
following modification:
>>>>>>>>>>>>
>>>>>>>>>>>> ------
>>>>>>>>>>>>
>>>>>>>>>>>> 3.1.  Data Provider Information
>>>>>>>>>>>>
>>>>>>>>>>>> This block MUST be provided by
>>>>>>>>>>>> * any service provider in the path of the call,
>>>>>>>>>>>> * the access network provider, and
>>>>>>>>>>>> * the device,
>>>>>>>>>>>> if these entities act as a source for additional data. 
The data provider information block offers identification and contact 
information of the data source
>>>>>>>>>>>>
>>>>>>>>>>>> The MIME subtype is "application/emergencyCall.ProviderInfo+xml".
>>>>>>>>>>>>
>>>>>>>>>>>> ------
>>>>>>>>>>>>
>>>>>>>>>>>> What do you think?
>>>>>>>>>>>>
>>>>>>>>>>>> Ciao
>>>>>>>>>>>> Hannes
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 08/07/2013 02:52 PM, Brian Rosen wrote:
>>>>>>>>>>>>> There is a requirement for multiple entities to add 
information.  I
>>>>>>>>>>>>> don't think there needs to be a requirement that it 
happen by value, but
>>>>>>>>>>>>> its at least desirable.
>>>>>>>>>>>>>
>>>>>>>>>>>>> James, it's perfectly clear that some blocks need to be 
repeated  For
>>>>>>>>>>>>> example the block that says who provided the data. 
Others are more
>>>>>>>>>>>>> specialized.  So generically, it's a requirement that 
at least some
>>>>>>>>>>>>> blocks are supplied by multiple enties.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Brian
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wednesday, August 7, 2013, James Winterbottom wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Actually, I think that the requirement is more whether a single
>>>>>>>>>>>>> entity should be able to add multiple types if information.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>> James
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 07/08/2013, at 4:32 PM, Christer Holmberg
>>>>>>>>>>>>> <christer.holmberg@ericsson.com <javascript:;>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Brian,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Not sure pictures in ascii art would help, but more 
words might.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think some ascii art, showing the calling device (user or
>>>>>>>>>>>>> sensor), some intermediary ("server") and the PSAP would help.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> My usual example is a medical sensor based device adds some, a
>>>>>>>>>>>>> specialized service provider who services the device 
adds some and a
>>>>>>>>>>>>> communications service provider adds some.  all of 
thise go in the
>>>>>>>>>>>>> SIP message.  then the access network sends some in the PIDF.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> With respect to multiple entities adding data, 
proxies can't add
>>>>>>>>>>>>> bodies, but B2BUAs can.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Well, that is protocol/solution talk - the question is whether
>>>>>>>>>>>>> there is a REQUIREMENT that multiple entities should be 
able to add
>>>>>>>>>>>>> information :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (If so, we then have to either mandate B2BUA functionality, or
>>>>>>>>>>>>> use some other mechanism. For example, data that can be 
defined as
>>>>>>>>>>>>> capabilities could be indicated also using feature capability
>>>>>>>>>>>>> indicators.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Christer
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> However, you have pointed out a problem that arose in the
>>>>>>>>>>>>> evolution of the mechanism.  Originally, there was an 
outer envelope
>>>>>>>>>>>>> wit the blocks inside it.  That would let us know the 
source of each
>>>>>>>>>>>>> block because the data provider block is required.   The current
>>>>>>>>>>>>> mechanism doesn't have that.  It's a problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Brian
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tuesday, August 6, 2013, Christer Holmberg wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The draft talks about all kind of different entities that might
>>>>>>>>>>>>> add additional data to an emergency call.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> First, I think it would be good to have some pictures showing a
>>>>>>>>>>>>> few different scenarios.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Second, the draft doesn't seem to describe the case where
>>>>>>>>>>>>> multiple entities are adding data - for the same call. 
Will multiple
>>>>>>>>>>>>> MIMEs etc be used, are there restrictions, etc etc etc? OR, is it
>>>>>>>>>>>>> not allowed to begin with?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Christer
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sent from Windows using TouchDown (www.nitrodesk.com
>>>>>>>>>>>>> <http://www.nitrodesk.com>)
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Ecrit mailing list
>>>>>>>>>>>>>> Ecrit@ietf.org <javascript:;>
>>>>>>>>>>>>>> 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



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I'm prepared for all emergencies but totally unprepared for
everyday life.

From keith.drage@alcatel-lucent.com  Sat Nov  2 08:04:53 2013
Return-Path: <keith.drage@alcatel-lucent.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 EF35F21E80C1 for <ecrit@ietfa.amsl.com>; Sat,  2 Nov 2013 08:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.701
X-Spam-Level: 
X-Spam-Status: No, score=-109.701 tagged_above=-999 required=5 tests=[AWL=-0.769, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyeA0pq3Srf0 for <ecrit@ietfa.amsl.com>; Sat,  2 Nov 2013 08:04:49 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDA921E809F for <ecrit@ietf.org>; Sat,  2 Nov 2013 08:04:45 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rA2F4box020153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 2 Nov 2013 10:04:38 -0500 (CDT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rA2F4Z9J001774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Nov 2013 16:04:35 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sat, 2 Nov 2013 16:04:35 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Randall Gellens <rg+ietf@qualcomm.com>, Christer Holmberg <christer.holmberg@ericsson.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, Roger Marshall <RMarshall@telecomsys.com>, "Brian Rosen" <br@brianrosen.net>
Thread-Topic: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of the Contact URI, defined in section 3.1.5
Thread-Index: AQHO13SLafEgX3wz20qzIyMwioZ+vJoR8YLw
Date: Sat, 2 Nov 2013 15:04:34 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0C65E1@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <7594FB04B1934943A5C02806D1A2204B1C41E812@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C422BC7@ESESSMB209.ericsson.se>, <CAOPrzE3XQGhXgH_zPpNDeLBrPb4hRUp2JefV2s9TqW1Ku0=RSA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C422DB7@ESESSMB209.ericsson.se> <FBD5AAFFD0978846BF6D3FAB4C892ACC3EDF01@SEA-EXMB-1.telecomsys.com>, <52669D95.8030501@gmx.net> <7594FB04B1934943A5C02806D1A2204B1C4EBC2B@ESESSMB209.ericsson.se> <p06240602ce9a13d807ee@[99.111.97.136]>
In-Reply-To: <p06240602ce9a13d807ee@[99.111.97.136]>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B0C65E1FR712WXCHMBA11zeu_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Cc: "ecrit_ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of the Contact URI, defined in section 3.1.5
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 02 Nov 2013 15:04:54 -0000

--_000_949EF20990823C4C85C18D59AA11AD8B0C65E1FR712WXCHMBA11zeu_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'd further say that if the PSAP has already tried the real contact informa=
tion and failed to establish a callback, it would seem entirely reasonable =
that the PSAP tries any other address in the message that might represent t=
he end user.

regards

Keith

________________________________
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R=
andall Gellens
Sent: 02 November 2013 02:35
To: Christer Holmberg; Hannes Tschofenig; Roger Marshall; Brian Rosen
Cc: ecrit_ietf.org
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope=
 of the Contact URI, defined in section 3.1.5

Do we really need to say MUST NOT?  Would it be sufficient to describe why =
the URL is not appropriate?  E.g., "Note that this contact information is n=
ot intended for nor is it suitable for a callback by a PSAP...."

At 6:43 PM +0000 10/22/13, Christer Holmberg wrote:

Content-Language: en-US
Content-Type: multipart/alternative;
     boundary=3D"_000_7594FB04B1934943A5C02806D1A2204B1C4EBC2BESESSMB209eri=
cs_"
Hi,


I would suggest that the contact information MUST NOT be used by the PSAP f=
or callbacks, and also say that the reason is because the contact informati=
on may not be associated with the user or the device that made the emergenc=
y call. No need to mention the Priority header field, simply refer to the p=
sap-callback draft.


Something like:


    "Note that this contact information MUST NOT be used by PSAPs for callb=
acks,
    as described in [I-D.ietf-ecrit-psap-callback], as the contact informat=
ion might
    not be associated with the user or device that made the emergency call.=
"


Regards,


Christer




________________________________
From: Hannes Tschofenig [hannes.tschofenig@gmx.net]
Sent: Tuesday, 22 October 2013 6:45 PM
To: Roger Marshall; Christer Holmberg; Brian Rosen
Cc: ecrit_ietf.org
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope=
 of the Contact URI, defined in section 3.1.5
Hi Christer,

as discussed in this email thread I added text for clarification:

----

3.1.5.  Data Provider Contact URI

    Data Element:  Data Provider Contact URI

    Use:  Required

    XML Element:  <ContactURI>

    Description:  When provided by a service provider or an access
       provider, this information MUST be a URI to a 24/7 support
       organization tasked to provide PSAP support for this emergency
       call.  If the call is from a device, this would reflect the
       contact information of the owner of the device.  If a telephone
       number is the contact address then it MUST be tel URI.  If it is
       provided as a SIP URI then it MUST be in the form of
       sip:telephonenumber@serviceprovider:user=3Dphone.  Note that this
       contact information is not used by PSAPs for callbacks using a SIP
       Priority header field with the value set to "psap- callback", as
       described in [I-D.ietf-ecrit-psap-callback].


----


Do you think that I managed to capture your concern?

Ciao
Hannes


On 08/26/2013 10:33 PM, Roger Marshall wrote:
> I agree with Christer=D5s suggestion to add caution text.
>
> -roger.
>
> *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf
> Of *Christer Holmberg
> *Sent:* Thursday, August 08, 2013 9:44 PM
> *To:* Brian Rosen
> *Cc:* ecrit_ietf.org
> *Subject:* Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on
> scope of the Contact URI, defined in section 3.1.5
>
> Hi,
>
> If the PSAP is not supposed to use the field when/if making a callback,
> I think we shall explicitly state that in the document, and/or in
> general say that the field must not be used for calls that are expected
> to be given priority/special handling, and give callback as an example.
>
> Regards,
>
> Christer
>
>
>
> Sent from */Windows/* using *TouchDown*(www.nitrodesk.com
> <<http:///>http://www.nitrodesk.com<http://www.nitrodesk.com/>>)
>
>
> -----Original Message-----
> *From:* Brian Rosen [br@brianrosen.net]
> *To:* Christer Holmberg [christer.holmberg@ericsson.com]
> *CC:* ecrit_ietf.org [ecrit@ietf.org]
> *Subject:* Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on
> scope of the Contact URI, defined in section 3.1.5
>
> The Contact is how the PSAP contacts the service provider to get help
> from the SP.
>
> It's not a "call back" in the sense of an emergency call (the network
> doesn't treat it differently than a normal call), at least as far as I
> have considered it.  I suppose it might be nice to know that it's
> important, but I don't think that is worth any big new mechanism.
>
> Brian
>
>
>
> On Thursday, August 8, 2013, Christer Holmberg wrote:
>
> I haven't seen any reply to this. Brian, do you have any opinion?
>
> Regards,
>
> Christer
>
>
>
> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com
> <<http:///>http://www.nitrodesk.com<http://www.nitrodesk.com/>>)
>
>
> -----Original Message-----
> *From:* Christer Holmberg [christer.holmberg@ericsson.com]
> *To:* ecrit@ietf.org [ecrit@ietf.org]
> *Subject:* [Ecrit] draft-ietf-ecrit-additional-data-11: Question on
> scope of the Contact URI, defined in section 3.1.5
>
> Hi,
>
> A question on the scope of the Contact URI, defined in section 3.1.5 of
> draft-ietf-ecrit-additional-data-11.txt.
>
> Is the Contact URI supposed by the PSAP when making callbacks?
>
> If the value represents a =D2service provider=D3, should PSAP callbacks a=
lso
> be made to the service provider?
>
> Regards,
>
> Christer
>
> CONFIDENTIALITY NOTICE: The information contained in this message may be
> privileged and/or confidential. If you are not the intended recipient,
> or responsible for delivering this message to the intended recipient,
> any review, forwarding, dissemination, distribution or copying of this
> communication or any attachment(s) is strictly prohibited. If you have
> received this message in error, please notify the sender immediately,
> and delete it and all attachments from your computer and network.
>
>
>
> _______________________________________________
> 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: ---------------
Blessed are the meek for they shall inhibit the earth.

--_000_949EF20990823C4C85C18D59AA11AD8B0C65E1FR712WXCHMBA11zeu_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<title>Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question</title>
<style type=3D"text/css">BLOCKQUOTE {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
DL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
UL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
OL {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
LI {
	PADDING-BOTTOM: 0px; PADDING-TOP: 0px
}
</style>
<meta content=3D"MSHTML 6.00.2900.6452" name=3D"GENERATOR">
</head>
<body>
<div dir=3D"ltr" align=3D"left"><span class=3D"359093413-02112013"><font fa=
ce=3D"Arial" color=3D"#0000ff" size=3D"2">I'd further say that if the PSAP =
has already tried the real contact information and failed to establish a ca=
llback, it would seem entirely reasonable that
 the PSAP tries any other address in the message that might represent the e=
nd user.</font></span></div>
<div dir=3D"ltr" align=3D"left"><span class=3D"359093413-02112013"><font fa=
ce=3D"Arial" color=3D"#0000ff" size=3D"2"></font></span>&nbsp;</div>
<div dir=3D"ltr" align=3D"left"><span class=3D"359093413-02112013"><font fa=
ce=3D"Arial" color=3D"#0000ff" size=3D"2">regards</font></span></div>
<div dir=3D"ltr" align=3D"left"><span class=3D"359093413-02112013"><font fa=
ce=3D"Arial" color=3D"#0000ff" size=3D"2"></font></span>&nbsp;</div>
<div dir=3D"ltr" align=3D"left"><span class=3D"359093413-02112013"><font fa=
ce=3D"Arial" color=3D"#0000ff" size=3D"2">Keith</font></span></div>
<br>
<blockquote dir=3D"ltr" style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDE=
R-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<div class=3D"OutlookMessageHeader" lang=3D"en-us" dir=3D"ltr" align=3D"lef=
t">
<hr tabindex=3D"-1">
<font face=3D"Tahoma" size=3D"2"><b>From:</b> ecrit-bounces@ietf.org [mailt=
o:ecrit-bounces@ietf.org]
<b>On Behalf Of </b>Randall Gellens<br>
<b>Sent:</b> 02 November 2013 02:35<br>
<b>To:</b> Christer Holmberg; Hannes Tschofenig; Roger Marshall; Brian Rose=
n<br>
<b>Cc:</b> ecrit_ietf.org<br>
<b>Subject:</b> Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o=
n scope of the Contact URI, defined in section 3.1.5<br>
</font><br>
</div>
<div></div>
<div>Do we really need to say MUST NOT?&nbsp; Would it be sufficient to des=
cribe why the URL is not appropriate?&nbsp; E.g., &quot;Note that this cont=
act information is not intended for nor is it suitable for a callback by a =
PSAP....&quot;</div>
<div><br>
</div>
<div>At 6:43 PM &#43;0000 10/22/13, Christer Holmberg wrote:</div>
<div><br>
</div>
<blockquote cite=3D"" type=3D"cite">Content-Language: en-US<br>
Content-Type: multipart/alternative;<br>
<X-TAB>&nbsp;&nbsp;&nbsp;&nbsp; </X-TAB>boundary=3D&quot;_000_7594FB04B1934=
943A5C02806D1A2204B1C4EBC2BESESSMB2<span></span>09erics_&quot;<br>
</blockquote>
<blockquote cite=3D"" type=3D"cite">Hi,<br>
</blockquote>
<blockquote cite=3D"" type=3D"cite"><br>
&nbsp;</blockquote>
<blockquote cite=3D"" type=3D"cite">I would&nbsp;suggest that the contact i=
nformation MUST NOT be used by the PSAP for callbacks, and also say that th=
e reason is because the contact information may not be associated with the =
user or the device that made the emergency
 call. No need to mention the Priority header field, simply refer to the ps=
ap-callback draft.<br>
</blockquote>
<blockquote cite=3D"" type=3D"cite"><br>
&nbsp;</blockquote>
<blockquote cite=3D"" type=3D"cite">Something like:<br>
</blockquote>
<blockquote cite=3D"" type=3D"cite"><br>
&nbsp;</blockquote>
<blockquote cite=3D"" type=3D"cite">&nbsp;&nbsp;&nbsp;&nbsp;&quot;Note that=
 this contact information&nbsp;MUST NOT be&nbsp;used by PSAPs for callbacks=
,<br>
</blockquote>
<blockquote cite=3D"" type=3D"cite">&nbsp;&nbsp;&nbsp;&nbsp;as described in=
 [I-D.ietf-ecrit-psap-callback], as the contact information might<br>
</blockquote>
<blockquote cite=3D"" type=3D"cite">&nbsp;&nbsp;&nbsp;&nbsp;not be associat=
ed with the user or device that made the emergency call.&quot;<br>
</blockquote>
<blockquote cite=3D"" type=3D"cite"><br>
&nbsp;</blockquote>
<blockquote cite=3D"" type=3D"cite">Regards,<br>
</blockquote>
<blockquote cite=3D"" type=3D"cite"><br>
&nbsp;</blockquote>
<blockquote cite=3D"" type=3D"cite">Christer<br>
</blockquote>
<blockquote cite=3D"" type=3D"cite"><br>
&nbsp;</blockquote>
<blockquote cite=3D"" type=3D"cite"><br>
&nbsp;</blockquote>
<blockquote cite=3D"" type=3D"cite">
<hr>
</blockquote>
<blockquote cite=3D"" type=3D"cite"><font face=3D"Tahoma" color=3D"#000000"=
><b>From:</b> Hannes Tschofenig [hannes.tschofenig@gmx.net]<br>
<b>Sent:</b> Tuesday, 22 October 2013 6:45 PM<br>
<b>To:</b> Roger Marshall; Christer Holmberg; Brian Rosen<br>
<b>Cc:</b> ecrit_ietf.org<br>
<b>Subject:</b> Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o=
n scope of the Contact URI, defined in section 3.1.5</font><br>
<font face=3D"Tahoma" color=3D"#000000"></font></blockquote>
<blockquote cite=3D"" type=3D"cite">Hi Christer,<br>
<br>
as discussed in this email thread I added text for clarification:<br>
<br>
----<br>
<br>
3.1.5.&nbsp; Data Provider Contact URI<br>
<br>
&nbsp;&nbsp;&nbsp; Data Element:&nbsp; Data Provider Contact URI<br>
<br>
&nbsp;&nbsp;&nbsp; Use:&nbsp; Required<br>
<br>
&nbsp;&nbsp;&nbsp; XML Element:&nbsp; &lt;ContactURI&gt;<br>
<br>
&nbsp;&nbsp;&nbsp; Description:&nbsp; When provided by a service provider o=
r an access<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; provider, this information MUST be a U=
RI to a 24/7 support<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; organization tasked to provide PSAP su=
pport for this emergency<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; call.&nbsp; If the call is from a devi=
ce, this would reflect the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contact information of the owner of th=
e device.&nbsp; If a telephone<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; number is the contact address then it =
MUST be tel URI.&nbsp; If it is<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; provided as a SIP URI then it MUST be =
in the form of<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sip:telephonenumber@serviceprovider:us=
er=3Dphone.&nbsp; Note that this<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contact information is not used by PSA=
Ps for callbacks using a SIP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Priority header field with the value s=
et to &quot;psap- callback&quot;, as<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; described in [I-D.ietf-ecrit-psap-call=
back].<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
----<br>
<br>
<br>
Do you think that I managed to capture your concern?<br>
<br>
Ciao<br>
Hannes<br>
<br>
<br>
On 08/26/2013 10:33 PM, Roger Marshall wrote:<br>
&gt; I agree with Christer=D5s suggestion to add caution text.<br>
&gt;<br>
&gt; -roger.<br>
&gt;<br>
&gt; *From:*ecrit-bounces@ietf.org [<a href=3D"mailto:ecrit-bounces@ietf.or=
g">mailto:ecrit-bounces@ietf.org</a>] *On Behalf<br>
&gt; Of *Christer Holmberg<br>
&gt; *Sent:* Thursday, August 08, 2013 9:44 PM<br>
&gt; *To:* Brian Rosen<br>
&gt; *Cc:* ecrit_ietf.org<br>
&gt; *Subject:* Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o=
n<br>
&gt; scope of the Contact URI, defined in section 3.1.5<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; If the PSAP is not supposed to use the field when/if making a callback=
,<br>
&gt; I think we shall explicitly state that in the document, and/or in<br>
&gt; general say that the field must not be used for calls that are expecte=
d<br>
&gt; to be given priority/special handling, and give callback as an example=
.<br>
&gt;<br>
&gt; Regards,<br>
&gt;<br>
&gt; Christer<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Sent from */Windows/* using *TouchDown*(<a href=3D"http:///">www.nitro=
desk.com<br>
&gt; &lt;</a><a href=3D"http://www.nitrodesk.com/">http://www.nitrodesk.com=
</a>&gt;)<br>
&gt;<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; *From:* Brian Rosen [br@brianrosen.net]<br>
&gt; *To:* Christer Holmberg [christer.holmberg@ericsson.com]<br>
&gt; *CC:* ecrit_ietf.org [ecrit@ietf.org]<br>
&gt; *Subject:* Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o=
n<br>
&gt; scope of the Contact URI, defined in section 3.1.5<br>
&gt;<br>
&gt; The Contact is how the PSAP contacts the service provider to get help<=
/blockquote>
<blockquote cite=3D"" type=3D"cite">&gt; from the SP.<br>
&gt;<br>
&gt; It's not a &quot;call back&quot; in the sense of an emergency call (th=
e network<br>
&gt; doesn't treat it differently than a normal call), at least as far as I=
<br>
&gt; have considered it.&nbsp; I suppose it might be nice to know that it's=
<br>
&gt; important, but I don't think that is worth any big new mechanism.<br>
&gt;<br>
&gt; Brian<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Thursday, August 8, 2013, Christer Holmberg wrote:<br>
&gt;<br>
&gt; I haven't seen any reply to this. Brian, do you have any opinion?<br>
&gt;<br>
&gt; Regards,<br>
&gt;<br>
&gt; Christer<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Sent from */Windows/* using *TouchDown* (<a href=3D"http:///">www.nitr=
odesk.com<br>
&gt; &lt;</a><a href=3D"http://www.nitrodesk.com/">http://www.nitrodesk.com=
</a>&gt;)<br>
&gt;<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; *From:* Christer Holmberg [christer.holmberg@ericsson.com]<br>
&gt; *To:* ecrit@ietf.org [ecrit@ietf.org]<br>
&gt; *Subject:* [Ecrit] draft-ietf-ecrit-additional-data-11: Question on<br=
>
&gt; scope of the Contact URI, defined in section 3.1.5<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; A question on the scope of the Contact URI, defined in section 3.1.5 o=
f<br>
&gt; draft-ietf-ecrit-additional-data-11.txt.<br>
&gt;<br>
&gt; Is the Contact URI supposed by the PSAP when making callbacks?<br>
&gt;<br>
&gt; If the value represents a =D2service provider=D3, should PSAP callback=
s also<br>
&gt; be made to the service provider?<br>
&gt;<br>
&gt; Regards,<br>
&gt;<br>
&gt; Christer<br>
&gt;<br>
&gt; CONFIDENTIALITY NOTICE: The information contained in this message may =
be<br>
&gt; privileged and/or confidential. If you are not the intended recipient,=
<br>
&gt; or responsible for delivering this message to the intended recipient,<=
br>
&gt; any review, forwarding, dissemination, distribution or copying of this=
<br>
&gt; communication or any attachment(s) is strictly prohibited. If you have=
<br>
&gt; received this message in error, please notify the sender immediately,<=
br>
&gt; and delete it and all attachments from your computer and network.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Ecrit mailing list<br>
&gt; Ecrit@ietf.org<br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/ecrit">https://www.ie=
tf.org/mailman/listinfo/ecrit</a><br>
&gt;<br>
</blockquote>
<blockquote cite=3D"" type=3D"cite"><br>
_______________________________________________<br>
Ecrit mailing list<br>
Ecrit@ietf.org<br>
https://www.ietf.org/mailman/listinfo/ecrit</blockquote>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<X-SIGSEP>
<pre>--=20
</pre>
</X-SIGSEP>
<div>Randall Gellens<br>
Opinions are personal;&nbsp;&nbsp;&nbsp; facts are suspect;&nbsp;&nbsp;&nbs=
p; I speak for myself only<br>
-------------- Randomly selected tag: ---------------<br>
Blessed are the meek for they shall inhibit the earth.<br>
</div>
</blockquote>
</body>
</html>

--_000_949EF20990823C4C85C18D59AA11AD8B0C65E1FR712WXCHMBA11zeu_--

From randy@qti.qualcomm.com  Sun Nov  3 09:26:12 2013
Return-Path: <randy@qti.qualcomm.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 EEF6011E821D for <ecrit@ietfa.amsl.com>; Sun,  3 Nov 2013 09:26:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.452
X-Spam-Level: 
X-Spam-Status: No, score=-105.452 tagged_above=-999 required=5 tests=[AWL=1.147, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iD4Z4QfipC0o for <ecrit@ietfa.amsl.com>; Sun,  3 Nov 2013 09:26:05 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCA811E8196 for <ecrit@ietf.org>; Sun,  3 Nov 2013 09:26:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1383499561; x=1415035561; h=message-id:date:to:from:subject:cc:mime-version; bh=fj82NjYlLLyvOs1yzvonKyvLE8QCgghPPP5WfRZQb68=; b=pAxNcpgMDF/og9jdWg07y8bdf57rH6rHRYQ6FVG1gbBiToRmlXJXfKVC rJRnzreVvqiQQRHcSbv3Xhvvh1QrLg3IPJ7rxZ+5qTArlL76MtEdsW5cn TCUUWYiCMg78KdI8nitHWdKCXodgKopATZCtCuJkvMrTvl0sgAu9a0Zj9 A=;
X-IronPort-AV: E=McAfee;i="5400,1158,7247"; a="84333307"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 03 Nov 2013 09:26:00 -0800
X-IronPort-AV: E=McAfee;i="5400,1158,7247"; a="542920015"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Nov 2013 09:26:00 -0800
Received: from dhcp-9302.meeting.ietf.org (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 3 Nov 2013 09:25:59 -0800
Message-ID: <p06240603ce9c338bedb6@dhcp-9302.meeting.ietf.org>
X-Mailer: Eudora for Mac OS X
Date: Sun, 3 Nov 2013 09:15:25 -0800
To: ECRIT WG <ecrit@ietf.org>
From: Randall Gellens <randy@qti.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [172.30.48.1]
Cc: Brian Rosen <Brian.Rosen@neustar.biz>, "Hannes \(NSN - FI/Espoo\) Tschofenig" <hannes.tschofenig@nsn.com>
Subject: [Ecrit] Block name terseness in additional-data draft
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 03 Nov 2013 17:26:12 -0000

I noticed that we are not consistent in the degree of terseness of 
the block names.  We have:

	o	ProviderInfo
	o	SvcInfo
	o	DevInfo
	o	SubInfo

I wonder if people feel we should have a consistent terseness level, 
and if so, consistently more or less so.  E.g., perhaps we should go 
with less terse and have:

	o	ProviderInfo
	o	ServiceInfo
	o	DeviceInfo
	o	SubscriberInfo

Or, perhaps we should go with more terse and have:

	o	PrvdrInfo
	o	SvcInfo
	o	DevInfo
	o	SubInfo

Personally, I'm inclined towards spending the extra few octets and 
going with the less terse names, as I suspect this may be easier for 
people to remember, and perhaps less likely to have spelling errors 
in implementations.  But I'd really like to know what others in the 
group think.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I always avoid prophesying beforehand, because it is a much better
policy to prophesy after the event has already taken place.
    --Winston Churchill

From gunnar.hellstrom@omnitor.se  Sun Nov  3 09:52:08 2013
Return-Path: <gunnar.hellstrom@omnitor.se>
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 1ABC311E82CA for <ecrit@ietfa.amsl.com>; Sun,  3 Nov 2013 09:52:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrn11xiqnufa for <ecrit@ietfa.amsl.com>; Sun,  3 Nov 2013 09:52:01 -0800 (PST)
Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with ESMTP id 801FB21E80BF for <ecrit@ietf.org>; Sun,  3 Nov 2013 09:52:00 -0800 (PST)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTPS for <ecrit@ietf.org>; Sun,  3 Nov 2013 18:51:51 +0100 (CET)
Received: from [192.168.50.32] (81-224-110-16-no227.business.telia.com [81.224.110.16]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-09-01.atm.binero.net (Postfix) with ESMTPA id 91D793A11F for <ecrit@ietf.org>; Sun,  3 Nov 2013 18:51:51 +0100 (CET)
Message-ID: <52768D39.3050005@omnitor.se>
Date: Sun, 03 Nov 2013 18:51:53 +0100
From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: ecrit@ietf.org
References: <p06240603ce9c338bedb6@dhcp-9302.meeting.ietf.org>
In-Reply-To: <p06240603ce9c338bedb6@dhcp-9302.meeting.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Ecrit] Block name terseness in additional-data draft
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 03 Nov 2013 17:52:08 -0000

I agree, the longer look better.
/Gunnar
On 2013-11-03 18:15, Randall Gellens wrote:
> I noticed that we are not consistent in the degree of terseness of the 
> block names.  We have:
>
>     o    ProviderInfo
>     o    SvcInfo
>     o    DevInfo
>     o    SubInfo
>
> I wonder if people feel we should have a consistent terseness level, 
> and if so, consistently more or less so.  E.g., perhaps we should go 
> with less terse and have:
>
>     o    ProviderInfo
>     o    ServiceInfo
>     o    DeviceInfo
>     o    SubscriberInfo
>
> Or, perhaps we should go with more terse and have:
>
>     o    PrvdrInfo
>     o    SvcInfo
>     o    DevInfo
>     o    SubInfo
>
> Personally, I'm inclined towards spending the extra few octets and 
> going with the less terse names, as I suspect this may be easier for 
> people to remember, and perhaps less likely to have spelling errors in 
> implementations.  But I'd really like to know what others in the group 
> think.
>


From christer.holmberg@ericsson.com  Sun Nov  3 10:10:21 2013
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 AE51921E80BF for <ecrit@ietfa.amsl.com>; Sun,  3 Nov 2013 10:10:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.568
X-Spam-Level: 
X-Spam-Status: No, score=-5.568 tagged_above=-999 required=5 tests=[AWL=0.680,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8A1RXp4CZxXJ for <ecrit@ietfa.amsl.com>; Sun,  3 Nov 2013 10:10:16 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D778E11E821C for <ecrit@ietf.org>; Sun,  3 Nov 2013 10:10:15 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-ea-52769186c214
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 53.FC.23787.68196725; Sun,  3 Nov 2013 19:10:14 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Sun, 3 Nov 2013 19:10:13 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>, Randall Gellens <rg+ietf@qualcomm.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>,  "Roger Marshall" <RMarshall@telecomsys.com>, Brian Rosen <br@brianrosen.net>
Thread-Topic: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of the Contact URI, defined in section 3.1.5
Thread-Index: AQHO19zcpctXjfUGaUeKdcQsnvq8npoTz3xg
Date: Sun, 3 Nov 2013 18:10:13 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C502B82@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C41E812@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C422BC7@ESESSMB209.ericsson.se>, <CAOPrzE3XQGhXgH_zPpNDeLBrPb4hRUp2JefV2s9TqW1Ku0=RSA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C422DB7@ESESSMB209.ericsson.se> <FBD5AAFFD0978846BF6D3FAB4C892ACC3EDF01@SEA-EXMB-1.telecomsys.com>, <52669D95.8030501@gmx.net> <7594FB04B1934943A5C02806D1A2204B1C4EBC2B@ESESSMB209.ericsson.se> <p06240602ce9a13d807ee@[99.111.97.136]> <949EF20990823C4C85C18D59AA11AD8B0C65E1@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0C65E1@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C502B82ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGfG3RrdtYlmQwar7ghZP709js2hc9JTV YunOe6wWTxvPMlp8OdzBanH46lImBzaP1md7WT3uf/vL7rF40342jyVLfjJ5bPrQzeqxYesp 5gC2KC6blNSczLLUIn27BK6MLVvFCx7fYKz4dOUYcwPjoT2MXYycHBICJhLzvl5jgrDFJC7c W8/WxcjFISRwiFFi0aOPrBDOYkaJL8+XsHQxcnCwCVhIdP/TBomLCDxhlDhzqYkdJM4soCxx ojMeZJCwQJVE42qQck6gmmqJLUc3MULYRhLbG1aBLWMRUJGYdbiTGcTmFfCV2H9jGhPErv0s Eg/2dIEVcQpES8yZ8hZsECPQdd9PrQGLMwuIS3w4eJ0Z4moBiSV7zkPZohIvH/9jhbCVJBbd /gxVny8x58w5dohlghInZz5hmcAoOgvJqFlIymYhKYOI60ncmDqFDcLWlli28DVUva7EjH+H WJDFFzCyr2Jkz03MzEkvN9zECIzTg1t+6+5gPHVO5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWp RfFFpTmpxYcYmTg4pRoYde9cknwbsOkFj4iX89I3J5ZeTnOI2fuQe9ftFgmzfa9tX2j/WvH8 uJhjRe/bhO8erkdZfmwJm+xt6tW66PW2Qg0DNWub/DOHhXmMnfsldXlnpJ3iZV0y/2NM8e5r Lt/2H5f0s1iX9PLEwo+rJwgesDz/gD350XsFUVu2Hx5pHJeqVky4Wnx/phJLcUaioRZzUXEi ANTsfrChAgAA
Cc: "ecrit_ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of the Contact URI, defined in section 3.1.5
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 03 Nov 2013 18:10:21 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1C502B82ESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I am ok with the suggestions below, if the PSAP callback using the "real" c=
ontact has failed.

The important thing is that the text is clear on that the contact informati=
on may not even point to the device/user that made the associated emergency=
 call.

Regards,

Christer




L=E4hett=E4j=E4: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.co=
m]
L=E4hetetty: 2. marraskuuta 2013 17:05
Vastaanottaja: Randall Gellens; Christer Holmberg; Hannes Tschofenig; Roger=
 Marshall; Brian Rosen
Kopio: ecrit_ietf.org
Aihe: RE: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of=
 the Contact URI, defined in section 3.1.5

I'd further say that if the PSAP has already tried the real contact informa=
tion and failed to establish a callback, it would seem entirely reasonable =
that the PSAP tries any other address in the message that might represent t=
he end user.

regards

Keith

________________________________
From: ecrit-bounces@ietf.org<mailto:ecrit-bounces@ietf.org> [mailto:ecrit-b=
ounces@ietf.org] On Behalf Of Randall Gellens
Sent: 02 November 2013 02:35
To: Christer Holmberg; Hannes Tschofenig; Roger Marshall; Brian Rosen
Cc: ecrit_ietf.org
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope=
 of the Contact URI, defined in section 3.1.5
Do we really need to say MUST NOT?  Would it be sufficient to describe why =
the URL is not appropriate?  E.g., "Note that this contact information is n=
ot intended for nor is it suitable for a callback by a PSAP...."

At 6:43 PM +0000 10/22/13, Christer Holmberg wrote:

Content-Language: en-US
Content-Type: multipart/alternative;
     boundary=3D"_000_7594FB04B1934943A5C02806D1A2204B1C4EBC2BESESSMB209eri=
cs_"
Hi,


I would suggest that the contact information MUST NOT be used by the PSAP f=
or callbacks, and also say that the reason is because the contact informati=
on may not be associated with the user or the device that made the emergenc=
y call. No need to mention the Priority header field, simply refer to the p=
sap-callback draft.


Something like:


    "Note that this contact information MUST NOT be used by PSAPs for callb=
acks,
    as described in [I-D.ietf-ecrit-psap-callback], as the contact informat=
ion might
    not be associated with the user or device that made the emergency call.=
"


Regards,


Christer




________________________________
From: Hannes Tschofenig [hannes.tschofenig@gmx.net]
Sent: Tuesday, 22 October 2013 6:45 PM
To: Roger Marshall; Christer Holmberg; Brian Rosen
Cc: ecrit_ietf.org
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope=
 of the Contact URI, defined in section 3.1.5
Hi Christer,

as discussed in this email thread I added text for clarification:

----

3.1.5.  Data Provider Contact URI

    Data Element:  Data Provider Contact URI

    Use:  Required

    XML Element:  <ContactURI>

    Description:  When provided by a service provider or an access
       provider, this information MUST be a URI to a 24/7 support
       organization tasked to provide PSAP support for this emergency
       call.  If the call is from a device, this would reflect the
       contact information of the owner of the device.  If a telephone
       number is the contact address then it MUST be tel URI.  If it is
       provided as a SIP URI then it MUST be in the form of
       sip:telephonenumber@serviceprovider:user=3Dphone.  Note that this
       contact information is not used by PSAPs for callbacks using a SIP
       Priority header field with the value set to "psap- callback", as
       described in [I-D.ietf-ecrit-psap-callback].


----


Do you think that I managed to capture your concern?

Ciao
Hannes


On 08/26/2013 10:33 PM, Roger Marshall wrote:
> I agree with Christer=D5s suggestion to add caution text.
>
> -roger.
>
> *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf
> Of *Christer Holmberg
> *Sent:* Thursday, August 08, 2013 9:44 PM
> *To:* Brian Rosen
> *Cc:* ecrit_ietf.org
> *Subject:* Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on
> scope of the Contact URI, defined in section 3.1.5
>
> Hi,
>
> If the PSAP is not supposed to use the field when/if making a callback,
> I think we shall explicitly state that in the document, and/or in
> general say that the field must not be used for calls that are expected
> to be given priority/special handling, and give callback as an example.
>
> Regards,
>
> Christer
>
>
>
> Sent from */Windows/* using *TouchDown*(www.nitrodesk.com
> <<http://>http://www.nitrodesk.com<http://www.nitrodesk.com/>>)
>
>
> -----Original Message-----
> *From:* Brian Rosen [br@brianrosen.net]
> *To:* Christer Holmberg [christer.holmberg@ericsson.com]
> *CC:* ecrit_ietf.org [ecrit@ietf.org]
> *Subject:* Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on
> scope of the Contact URI, defined in section 3.1.5
>
> The Contact is how the PSAP contacts the service provider to get help
> from the SP.
>
> It's not a "call back" in the sense of an emergency call (the network
> doesn't treat it differently than a normal call), at least as far as I
> have considered it.  I suppose it might be nice to know that it's
> important, but I don't think that is worth any big new mechanism.
>
> Brian
>
>
>
> On Thursday, August 8, 2013, Christer Holmberg wrote:
>
> I haven't seen any reply to this. Brian, do you have any opinion?
>
> Regards,
>
> Christer
>
>
>
> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com
> <<http://>http://www.nitrodesk.com<http://www.nitrodesk.com/>>)
>
>
> -----Original Message-----
> *From:* Christer Holmberg [christer.holmberg@ericsson.com]
> *To:* ecrit@ietf.org<mailto:ecrit@ietf.org> [ecrit@ietf.org]
> *Subject:* [Ecrit] draft-ietf-ecrit-additional-data-11: Question on
> scope of the Contact URI, defined in section 3.1.5
>
> Hi,
>
> A question on the scope of the Contact URI, defined in section 3.1.5 of
> draft-ietf-ecrit-additional-data-11.txt.
>
> Is the Contact URI supposed by the PSAP when making callbacks?
>
> If the value represents a =D2service provider=D3, should PSAP callbacks a=
lso
> be made to the service provider?
>
> Regards,
>
> Christer
>
> CONFIDENTIALITY NOTICE: The information contained in this message may be
> privileged and/or confidential. If you are not the intended recipient,
> or responsible for delivering this message to the intended recipient,
> any review, forwarding, dissemination, distribution or copying of this
> communication or any attachment(s) is strictly prohibited. If you have
> received this message in error, please notify the sender immediately,
> and delete it and all attachments from your computer and network.
>
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org<mailto:Ecrit@ietf.org>
> https://www.ietf.org/mailman/listinfo/ecrit
>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org<mailto: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: ---------------
Blessed are the meek for they shall inhibit the earth.

--_000_7594FB04B1934943A5C02806D1A2204B1C502B82ESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<title>Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question</title>
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 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:12.0pt;
	font-family:"Times New Roman","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;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML-esimuotoiltu Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Seliteteksti Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.HTML-esimuotoiltuChar
	{mso-style-name:"HTML-esimuotoiltu Char";
	mso-style-priority:99;
	mso-style-link:HTML-esimuotoiltu;
	font-family:"Consolas","serif";}
span.Shkpostityyli19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.SelitetekstiChar
	{mso-style-name:"Seliteteksti Char";
	mso-style-priority:99;
	mso-style-link:Seliteteksti;
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 2.0cm 70.85pt 2.0cm;}
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"FI" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi,<o:p></=
o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">I am ok wi=
th the suggestions below, if the PSAP callback using the &#8220;real&#8221;=
 contact has failed.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">The import=
ant thing is that the text is clear on that the contact information may not=
 even point to the device/user that made the associated emergency
 call.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Regards,<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Christer<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">L=E4hett=E4j=E4:</span=
></b><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot;Tahom=
a&quot;,&quot;sans-serif&quot;"> DRAGE, Keith (Keith) [mailto:keith.drage@a=
lcatel-lucent.com]
<br>
<b>L=E4hetetty:</b> 2. </span><span style=3D"font-size:10.0pt;font-family:&=
quot;Tahoma&quot;,&quot;sans-serif&quot;">marraskuuta 2013 17:05<br>
<b>Vastaanottaja:</b> Randall Gellens; Christer Holmberg; Hannes Tschofenig=
; Roger Marshall; Brian Rosen<br>
<b>Kopio:</b> ecrit_ietf.org<br>
<b>Aihe:</b> RE: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on s=
cope of the Contact URI, defined in section 3.1.5<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:blue">I'd further say that if the PS=
AP has already tried the real contact information and failed to establish a=
 callback, it would seem entirely reasonable that the PSAP
 tries any other address in the message that might represent the end user.<=
/span><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:blue">regards</span><o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:&quot;Ar=
ial&quot;,&quot;sans-serif&quot;;color:blue">Keith</span><o:p></o:p></p>
<blockquote style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0=
cm 0cm 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bo=
ttom:5.0pt">
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span=
 lang=3D"EN-US">
<hr size=3D"2" width=3D"100%" align=3D"center">
</span></div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span lang=3D"EN-U=
S" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-seri=
f&quot;">From:</span></b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fon=
t-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
<a href=3D"mailto:ecrit-bounces@ietf.org">ecrit-bounces@ietf.org</a> [<a hr=
ef=3D"mailto:ecrit-bounces@ietf.org">mailto:ecrit-bounces@ietf.org</a>]
<b>On Behalf Of </b>Randall Gellens<br>
<b>Sent:</b> 02 November 2013 02:35<br>
<b>To:</b> Christer Holmberg; Hannes Tschofenig; Roger Marshall; Brian Rose=
n<br>
<b>Cc:</b> ecrit_ietf.org<br>
<b>Subject:</b> Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o=
n scope of the Contact URI, defined in section 3.1.5</span><span lang=3D"EN=
-US"><o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal">Do we really need to say MUST NOT?&nbsp; Would it be=
 sufficient to describe why the URL is not appropriate?&nbsp; E.g., &quot;N=
ote that this contact information is not intended for nor is it suitable fo=
r a callback by a PSAP....&quot;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">At 6:43 PM &#43;0000 10/22/13, Christer Holmberg wro=
te:<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal">Content-Language: en-US<br>
Content-Type: multipart/alternative;<br>
&nbsp;&nbsp;&nbsp;&nbsp; boundary=3D&quot;_000_7594FB04B1934943A5C02806D1A2=
204B1C4EBC2BESESSMB209erics_&quot;<o:p></o:p></p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal">Hi,<o:p></o:p></p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal"><br>
&nbsp;<o:p></o:p></p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal">I would&nbsp;suggest that the contact information MU=
ST NOT be used by the PSAP for callbacks, and also say that the reason is b=
ecause the contact information may not be associated with the user or the d=
evice that made the emergency call. No
 need to mention the Priority header field, simply refer to the psap-callba=
ck draft.<o:p></o:p></p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal"><br>
&nbsp;<o:p></o:p></p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal">Something like:<o:p></o:p></p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal"><br>
&nbsp;<o:p></o:p></p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;&quot;Note that this contact=
 information&nbsp;MUST NOT be&nbsp;used by PSAPs for callbacks,<o:p></o:p><=
/p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;as described in [I-D.ietf-ec=
rit-psap-callback], as the contact information might<o:p></o:p></p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp;&nbsp;not be associated with the u=
ser or device that made the emergency call.&quot;<o:p></o:p></p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal"><br>
&nbsp;<o:p></o:p></p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal">Regards,<o:p></o:p></p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal"><br>
&nbsp;<o:p></o:p></p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal">Christer<o:p></o:p></p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal"><br>
&nbsp;<o:p></o:p></p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal"><br>
&nbsp;<o:p></o:p></p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">
<hr size=3D"2" width=3D"100%" align=3D"center">
</div>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal"><b><span style=3D"font-family:&quot;Tahoma&quot;,&qu=
ot;sans-serif&quot;;color:black">From:</span></b><span style=3D"font-family=
:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:black"> Hannes Tschofenig =
[hannes.tschofenig@gmx.net]<br>
<b>Sent:</b> Tuesday, 22 October 2013 6:45 PM<br>
<b>To:</b> Roger Marshall; Christer Holmberg; Brian Rosen<br>
<b>Cc:</b> ecrit_ietf.org<br>
<b>Subject:</b> Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o=
n scope of the Contact URI, defined in section 3.1.5</span><o:p></o:p></p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal">Hi Christer,<br>
<br>
as discussed in this email thread I added text for clarification:<br>
<br>
----<br>
<br>
3.1.5.&nbsp; Data Provider Contact URI<br>
<br>
&nbsp;&nbsp;&nbsp; Data Element:&nbsp; Data Provider Contact URI<br>
<br>
&nbsp;&nbsp;&nbsp; Use:&nbsp; Required<br>
<br>
&nbsp;&nbsp;&nbsp; XML Element:&nbsp; &lt;ContactURI&gt;<br>
<br>
&nbsp;&nbsp;&nbsp; Description:&nbsp; When provided by a service provider o=
r an access<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; provider, this information MUST be a U=
RI to a 24/7 support<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; organization tasked to provide PSAP su=
pport for this emergency<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; call.&nbsp; If the call is from a devi=
ce, this would reflect the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contact information of the owner of th=
e device.&nbsp; If a telephone<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; number is the contact address then it =
MUST be tel URI.&nbsp; <span lang=3D"EN-US">
If it is<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; provided as a SIP URI then it MUST be =
in the form of<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><a href=3D"sip:telephonenumber@=
serviceprovider:user=3Dphone"><span lang=3D"EN-US">sip:telephonenumber@serv=
iceprovider:user=3Dphone</span></a><span lang=3D"EN-US">.&nbsp;
</span>Note that this<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contact information is not used by PSA=
Ps for callbacks using a SIP<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Priority header field with the value s=
et to &quot;psap- callback&quot;, as<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; described in [I-D.ietf-ecrit-psap-call=
back].<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
----<br>
<br>
<br>
Do you think that I managed to capture your concern?<br>
<br>
Ciao<br>
Hannes<br>
<br>
<br>
On 08/26/2013 10:33 PM, Roger Marshall wrote:<br>
&gt; I agree with Christer=D5s suggestion to add caution text.<br>
&gt;<br>
&gt; -roger.<br>
&gt;<br>
&gt; *From:*ecrit-bounces@ietf.org [<a href=3D"mailto:ecrit-bounces@ietf.or=
g">mailto:ecrit-bounces@ietf.org</a>] *On Behalf<br>
&gt; Of *Christer Holmberg<br>
&gt; *Sent:* Thursday, August 08, 2013 9:44 PM<br>
&gt; *To:* Brian Rosen<br>
&gt; *Cc:* ecrit_ietf.org<br>
&gt; *Subject:* Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o=
n<br>
&gt; scope of the Contact URI, defined in section 3.1.5<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; If the PSAP is not supposed to use the field when/if making a callback=
,<br>
&gt; I think we shall explicitly state that in the document, and/or in<br>
&gt; general say that the field must not be used for calls that are expecte=
d<br>
&gt; to be given priority/special handling, and give callback as an example=
.<br>
&gt;<br>
&gt; Regards,<br>
&gt;<br>
&gt; Christer<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Sent from */Windows/* using *TouchDown*(<a href=3D"http://">www.nitrod=
esk.com<br>
&gt; &lt;</a><a href=3D"http://www.nitrodesk.com/">http://www.nitrodesk.com=
</a>&gt;)<br>
&gt;<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; *From:* Brian Rosen [br@brianrosen.net]<br>
&gt; *To:* Christer Holmberg [christer.holmberg@ericsson.com]<br>
&gt; *CC:* ecrit_ietf.org [ecrit@ietf.org]<br>
&gt; *Subject:* Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o=
n<br>
&gt; scope of the Contact URI, defined in section 3.1.5<br>
&gt;<br>
&gt; The Contact is how the PSAP contacts the service provider to get help<=
o:p></o:p></p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal">&gt; from the SP.<br>
&gt;<br>
&gt; It's not a &quot;call back&quot; in the sense of an emergency call (th=
e network<br>
&gt; doesn't treat it differently than a normal call), at least as far as I=
<br>
&gt; have considered it.&nbsp; I suppose it might be nice to know that it's=
<br>
&gt; important, but I don't think that is worth any big new mechanism.<br>
&gt;<br>
&gt; Brian<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Thursday, August 8, 2013, Christer Holmberg wrote:<br>
&gt;<br>
&gt; I haven't seen any reply to this. Brian, do you have any opinion?<br>
<span lang=3D"EN-US">&gt;<br>
&gt; Regards,<br>
&gt;<br>
&gt; Christer<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Sent from */Windows/* using *TouchDown* (</span><a href=3D"http://"><s=
pan lang=3D"EN-US">www.nitrodesk.com<br>
&gt; &lt;</span></a><a href=3D"http://www.nitrodesk.com/"><span lang=3D"EN-=
US">http://www.nitrodesk.com</span></a><span lang=3D"EN-US">&gt;)<br>
&gt;<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; *From:* Christer Holmberg [christer.holmberg@ericsson.com]<br>
&gt; *To:* </span><a href=3D"mailto:ecrit@ietf.org"><span lang=3D"EN-US">ec=
rit@ietf.org</span></a><span lang=3D"EN-US"> [ecrit@ietf.org]<br>
&gt; *Subject:* [Ecrit] draft-ietf-ecrit-additional-data-11: Question on<br=
>
&gt; scope of the Contact URI, defined in section 3.1.5<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; A question on the scope of the Contact URI, defined in section 3.1.5 o=
f<br>
&gt; draft-ietf-ecrit-additional-data-11.txt.<br>
&gt;<br>
&gt; Is the Contact URI supposed by the PSAP when making callbacks?<br>
&gt;<br>
&gt; If the value represents a =D2service provider=D3, s</span>hould PSAP c=
allbacks also<br>
&gt; be made to the service provider?<br>
&gt;<br>
&gt; Regards,<br>
&gt;<br>
&gt; Christer<br>
&gt;<br>
&gt; CONFIDENTIALITY NOTICE: The information contained in this message may =
be<br>
&gt; privileged and/or confidential. If you are not the intended recipient,=
<br>
&gt; or responsible for delivering this message to the intended recipient,<=
br>
&gt; any review, forwarding, dissemination, distribution or copying of this=
<br>
&gt; communication or any attachment(s) is strictly prohibited. If you have=
<br>
&gt; received this message in error, please notify the sender immediately,<=
br>
&gt; and delete it and all attachments from your computer and network.<br>
<span lang=3D"EN-US">&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Ecrit mailing list<br>
&gt; </span><a href=3D"mailto:Ecrit@ietf.org"><span lang=3D"EN-US">Ecrit@ie=
tf.org</span></a><span lang=3D"EN-US"><br>
&gt; </span><a href=3D"https://www.ietf.org/mailman/listinfo/ecrit"><span l=
ang=3D"EN-US">https://www.ietf.org/mailman/listinfo/ecrit</span></a><span l=
ang=3D"EN-US"><br>
&gt;<o:p></o:p></span></p>
</blockquote>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal"><span lang=3D"EN-US"><br>
_______________________________________________<br>
Ecrit mailing list<br>
</span><a href=3D"mailto:Ecrit@ietf.org"><span lang=3D"EN-US">Ecrit@ietf.or=
g</span></a><span lang=3D"EN-US"><br>
</span><a href=3D"https://www.ietf.org/mailman/listinfo/ecrit"><span lang=
=3D"EN-US">https://www.ietf.org/mailman/listinfo/ecrit</span></a><span lang=
=3D"EN-US"><o:p></o:p></span></p>
</blockquote>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
<pre>-- <o:p></o:p></pre>
<div>
<p class=3D"MsoNormal">Randall Gellens<br>
Opinions are personal;&nbsp;&nbsp;&nbsp; facts are suspect;&nbsp;&nbsp;&nbs=
p; I speak for myself only<br>
-------------- Randomly selected tag: ---------------<br>
Blessed are the meek for they shall inhibit the earth.<o:p></o:p></p>
</div>
</blockquote>
</div>
</body>
</html>

--_000_7594FB04B1934943A5C02806D1A2204B1C502B82ESESSMB209erics_--

From RMarshall@telecomsys.com  Sun Nov  3 10:16:55 2013
Return-Path: <RMarshall@telecomsys.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 5B4A211E82CC for <ecrit@ietfa.amsl.com>; Sun,  3 Nov 2013 10:16:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGln5HKv1xBm for <ecrit@ietfa.amsl.com>; Sun,  3 Nov 2013 10:16:51 -0800 (PST)
Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id C241A11E821E for <ecrit@ietf.org>; Sun,  3 Nov 2013 10:16:50 -0800 (PST)
Received: from SEA-EXCAS-1.telecomsys.com  (exc2010-local1.telecomsys.com [10.32.12.186]) by  sea-mx-02.telecomsys.com (8.14.5/8.14.5) with ESMTP id rA3IGmGW011233  (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Sun, 3  Nov 2013 10:16:48 -0800
Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.197]) by  SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Sun,  3 Nov 2013 10:16:47 -0800
From: Roger Marshall <RMarshall@telecomsys.com>
To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
Thread-Topic: [Ecrit] Block name terseness in additional-data draft
Thread-Index: AQHO2LnH1IzI3pRyZkKUqTH1ssCF6JoUT2qA//+A2XQ=
Date: Sun, 3 Nov 2013 18:16:47 +0000
Message-ID: <EB5BDE6B-5FE2-4433-9CCD-C6FDC9B487F5@telecomsys.com>
References: <p06240603ce9c338bedb6@dhcp-9302.meeting.ietf.org>, <52768D39.3050005@omnitor.se>
In-Reply-To: <52768D39.3050005@omnitor.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] Block name terseness in additional-data draft
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 03 Nov 2013 18:16:55 -0000

I agree to the longer styles - per the examples, at least.

Sent from my mobile device

On Nov 3, 2013, at 9:52 AM, "Gunnar Hellstrom" <gunnar.hellstrom@omnitor.se=
> wrote:

> I agree, the longer look better.
> /Gunnar
> On 2013-11-03 18:15, Randall Gellens wrote:
>> I noticed that we are not consistent in the degree of terseness of the b=
lock names.  We have:
>>=20
>>    o    ProviderInfo
>>    o    SvcInfo
>>    o    DevInfo
>>    o    SubInfo
>>=20
>> I wonder if people feel we should have a consistent terseness level, and=
 if so, consistently more or less so.  E.g., perhaps we should go with less=
 terse and have:
>>=20
>>    o    ProviderInfo
>>    o    ServiceInfo
>>    o    DeviceInfo
>>    o    SubscriberInfo
>>=20
>> Or, perhaps we should go with more terse and have:
>>=20
>>    o    PrvdrInfo
>>    o    SvcInfo
>>    o    DevInfo
>>    o    SubInfo
>>=20
>> Personally, I'm inclined towards spending the extra few octets and going=
 with the less terse names, as I suspect this may be easier for people to r=
emember, and perhaps less likely to have spelling errors in implementations=
.  But I'd really like to know what others in the group think.
>>=20
>=20
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit

CONFIDENTIALITY NOTICE: The information contained in this message may be pr=
ivileged and/or confidential. If you are not the intended recipient, or res=
ponsible for delivering this message to the intended recipient, any review,=
 forwarding, dissemination, distribution or copying of this communication o=
r any attachment(s) is strictly prohibited. If you have received this messa=
ge in error, please notify the sender immediately, and delete it and all at=
tachments from your computer and network.

From a.james.winterbottom@gmail.com  Sun Nov  3 11:23:56 2013
Return-Path: <a.james.winterbottom@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 EB44911E8226 for <ecrit@ietfa.amsl.com>; Sun,  3 Nov 2013 11:23:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Level: 
X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn6DIgvY14l7 for <ecrit@ietfa.amsl.com>; Sun,  3 Nov 2013 11:23:56 -0800 (PST)
Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9B911E8190 for <ecrit@ietf.org>; Sun,  3 Nov 2013 11:23:56 -0800 (PST)
Received: by mail-pd0-f175.google.com with SMTP id g10so5864030pdj.34 for <ecrit@ietf.org>; Sun, 03 Nov 2013 11:23:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=P7JxrTikc1PmUbiN8BayvS5nQ1AazT5tv/+mAwr/SUI=; b=Ei4F8VKNrLhYC+KAmnpFyz0IynyNAV+ixf1jbMwu3YX9QOvMaaBohoa0dtADbZ3Y/M Aig3tbc/GRHuV+q69QAD57zc+icTkZB0o6SOGV9ksbiW+H4y740jqcJQPEY+zRZdhWBx w5i8dzXHexD9HnYWnFdQFmclhiKx2EatvPiql1bxkCKYzsoDkyJm+ia81Fo1a2SnP2s3 yIzMBp+x9/Uv+8x5tTWjYQXtDlsPiygnLokjoBTFhrpc9jtFtYuFlXupUSZV6RAU3bWe TWTOeaeQ/tXlULrqrwepnz4huXgR1iLSjJVyZz0BT13oEvGwcKIQUAw7Hy/tXqIYZMeK joGQ==
X-Received: by 10.68.225.9 with SMTP id rg9mr14139873pbc.122.1383506635500; Sun, 03 Nov 2013 11:23:55 -0800 (PST)
Received: from [192.168.1.14] (124-149-67-181.dyn.iinet.net.au. [124.149.67.181]) by mx.google.com with ESMTPSA id nj9sm23631359pbc.13.2013.11.03.11.23.53 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 11:23:54 -0800 (PST)
References: <p06240603ce9c338bedb6@dhcp-9302.meeting.ietf.org> <52768D39.3050005@omnitor.se>
Mime-Version: 1.0 (1.0)
In-Reply-To: <52768D39.3050005@omnitor.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <ABAEBFEB-D2A0-4CBE-9C16-D3F60C2D8AD2@gmail.com>
X-Mailer: iPad Mail (10B329)
From: James Winterbottom <a.james.winterbottom@gmail.com>
Date: Mon, 4 Nov 2013 06:23:52 +1100
To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] Block name terseness in additional-data draft
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 03 Nov 2013 19:23:57 -0000

+1

Sent from my iPad

On 04/11/2013, at 4:51 AM, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wr=
ote:

> I agree, the longer look better.
> /Gunnar
> On 2013-11-03 18:15, Randall Gellens wrote:
>> I noticed that we are not consistent in the degree of terseness of the bl=
ock names.  We have:
>>=20
>>    o    ProviderInfo
>>    o    SvcInfo
>>    o    DevInfo
>>    o    SubInfo
>>=20
>> I wonder if people feel we should have a consistent terseness level, and i=
f so, consistently more or less so.  E.g., perhaps we should go with less te=
rse and have:
>>=20
>>    o    ProviderInfo
>>    o    ServiceInfo
>>    o    DeviceInfo
>>    o    SubscriberInfo
>>=20
>> Or, perhaps we should go with more terse and have:
>>=20
>>    o    PrvdrInfo
>>    o    SvcInfo
>>    o    DevInfo
>>    o    SubInfo
>>=20
>> Personally, I'm inclined towards spending the extra few octets and going w=
ith the less terse names, as I suspect this may be easier for people to reme=
mber, and perhaps less likely to have spelling errors in implementations.  B=
ut I'd really like to know what others in the group think.
>=20
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit

From internet-drafts@ietf.org  Mon Nov  4 02:41:53 2013
Return-Path: <internet-drafts@ietf.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 6EB7511E81CA; Mon,  4 Nov 2013 02:41:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.567
X-Spam-Level: 
X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9g2+H7+RQDP4; Mon,  4 Nov 2013 02:41:51 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A065311E81B2; Mon,  4 Nov 2013 02:28:47 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.82
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131104102847.10115.77054.idtracker@ietfa.amsl.com>
Date: Mon, 04 Nov 2013 02:28:47 -0800
Cc: ecrit@ietf.org
Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-15.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 04 Nov 2013 10:41:53 -0000

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 Interne=
t Technologies Working Group of the IETF.

	Title           : Additional Data related to an Emergency Call
	Author(s)       : Brian Rosen
                          Hannes Tschofenig
                          Roger Marshall
                          Randall Gellens
                          James Winterbottom
	Filename        : draft-ietf-ecrit-additional-data-15.txt
	Pages           : 97
	Date            : 2013-11-04

Abstract:
   When an emergency call is sent to a Public Safety Answering Point
   (PSAP), the device that sends it, as well as any application service
   provider in the path of the call, or access network provider through
   which the call originated may have information about the call, the
   caller or the location which the PSAP may be able to use.  This
   document describes data structures and a mechanism to convey such
   data to the PSAP.  The mechanism uses a Uniform Resource Identifier
   (URI), which may point to either an external resource or an object in
   the body of the SIP message.  The mechanism thus allows the data to
   be passed by reference (when the URI points to an external resource)
   or by value (when it points into the body of the message).  This
   follows the tradition of prior emergency services standardization
   work where data can be conveyed by value within the call signaling
   (i.e., in body of the SIP message) and also by reference.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-15

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-15


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 internet-drafts@ietf.org  Mon Nov  4 10:10:23 2013
Return-Path: <internet-drafts@ietf.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 9CEB921E81C4; Mon,  4 Nov 2013 10:10:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.568
X-Spam-Level: 
X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LCNZFOS2Hgm; Mon,  4 Nov 2013 10:10:23 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4068A11E810E; Mon,  4 Nov 2013 10:10:20 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.82
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131104181020.10152.37518.idtracker@ietfa.amsl.com>
Date: Mon, 04 Nov 2013 10:10:20 -0800
Cc: ecrit@ietf.org
Subject: [Ecrit] I-D Action: draft-ietf-ecrit-country-emg-urn-01.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 04 Nov 2013 18:10:23 -0000

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 Interne=
t Technologies Working Group of the IETF.

	Title           : URN For Country Specific Emergency Services
	Author(s)       : Christer Holmberg
                          Ivo Sedlacek
	Filename        : draft-ietf-ecrit-country-emg-urn-01.txt
	Pages           : 7
	Date            : 2013-11-04

Abstract:
   This document updates section 4.2 of RFC 5031, in order to allow the
   registration of service URNs with the 'sos' service type for
   emergency services that, at the time of registration, are offered in
   one country only.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ecrit-country-emg-urn-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-country-emg-urn-01


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 brian.rosen@neustar.biz  Mon Nov  4 10:45:01 2013
Return-Path: <brian.rosen@neustar.biz>
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 A698021E815D for <ecrit@ietfa.amsl.com>; Mon,  4 Nov 2013 10:45:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.158
X-Spam-Level: 
X-Spam-Status: No, score=-6.158 tagged_above=-999 required=5 tests=[AWL=0.440,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fp7jGI2fexjK for <ecrit@ietfa.amsl.com>; Mon,  4 Nov 2013 10:44:53 -0800 (PST)
Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 848DC11E815F for <ecrit@ietf.org>; Mon,  4 Nov 2013 10:44:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1383590847; x=1698946460; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=ZxsNY8k2SZhq3ruiv9DUkcu2i6lqnuy9fIdYq42Q4jk=; b=iDX/6Gu015p9mg75QfPwcuIHe/T85JRz+k0sdSeiJUV4f85EozrZCv9vojNyWH /BHIiq1sF/cflmLdBQ2Iycfg==
Received: from ([10.31.58.70]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.33260244;  Mon, 04 Nov 2013 13:47:26 -0500
Received: from STNTEXMB10.cis.neustar.com ([169.254.5.60]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 4 Nov 2013 13:44:37 -0500
From: "Rosen, Brian" <Brian.Rosen@neustar.biz>
To: ecrit <ecrit@ietf.org>
Thread-Topic: I-D Action: draft-rosen-ecrit-lost-planned-changes-00.txt
Thread-Index: AQHO2Y3pDDV0O6AeWEenAV38rmrU1Q==
Date: Mon, 4 Nov 2013 18:44:37 +0000
Message-ID: <B922BAA5-1ED3-4367-A0D6-BB15B1C25BE0@neustar.biz>
References: <20131104182456.10133.11467.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.128.255]
x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA==
x-ems-stamp: 4rkryo1gqdzOAs4H2FOO6g==
Content-Type: multipart/alternative; boundary="_000_B922BAA51ED34367A0D6BB15B1C25BE0neustarbiz_"
MIME-Version: 1.0
Subject: [Ecrit] Fwd: I-D Action: draft-rosen-ecrit-lost-planned-changes-00.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 04 Nov 2013 18:45:02 -0000

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

The draft is now available in the repository.

Begin forwarded message:

From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Subject: I-D Action: draft-rosen-ecrit-lost-planned-changes-00.txt
Date: November 4, 2013 at 10:24:56 AM PST
To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>
Reply-To: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.


Title           : Validation of Locations Around a Planned Change
Author(s)       : Brian Rosen
Filename        : draft-rosen-ecrit-lost-planned-changes-00.txt
Pages           : 8
Date            : 2013-11-04

Abstract:
  This document defines an extension to LoST (RFC5222) that allows a
  planned change to the data in the LoST server to occur.  Records that
  previously were valid will become invalid at a date in the future,
  and new locations will become valid after the date.  The extension
  adds two elements to the <findservice> request: a URI to be used to
  inform the LIS that previously valid locations will be invalid after
  the planned change date, and add a date which requests the server to
  perform validation as of the date specified.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-rosen-ecrit-lost-planned-changes

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-rosen-ecrit-lost-planned-changes-00


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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--_000_B922BAA51ED34367A0D6BB15B1C25BE0neustarbiz_
Content-Type: text/html; charset="us-ascii"
Content-ID: <781A609E5FE4C34487318CF49C2B01D9@neustar.biz>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space;">
The draft is now available in the repository.&nbsp;<br>
<div><br>
<div>Begin forwarded message:</div>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">
<div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margi=
n-left: 0px;">
<span style=3D"font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>From:=
 </b></span><span style=3D"font-family:'Helvetica';"><a href=3D"mailto:inte=
rnet-drafts@ietf.org">internet-drafts@ietf.org</a><br>
</span></div>
<div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margi=
n-left: 0px;">
<span style=3D"font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>Subje=
ct: </b>
</span><span style=3D"font-family:'Helvetica';"><b>I-D Action: draft-rosen-=
ecrit-lost-planned-changes-00.txt</b><br>
</span></div>
<div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margi=
n-left: 0px;">
<span style=3D"font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>Date:=
 </b></span><span style=3D"font-family:'Helvetica';">November 4, 2013 at 10=
:24:56 AM PST<br>
</span></div>
<div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margi=
n-left: 0px;">
<span style=3D"font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>To: <=
/b></span><span style=3D"font-family:'Helvetica';"><a href=3D"mailto:i-d-an=
nounce@ietf.org">i-d-announce@ietf.org</a><br>
</span></div>
<div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margi=
n-left: 0px;">
<span style=3D"font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>Reply=
-To: </b>
</span><span style=3D"font-family:'Helvetica';"><a href=3D"mailto:internet-=
drafts@ietf.org">internet-drafts@ietf.org</a><br>
</span></div>
<br>
<div><br>
A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.<br>
<br>
<br>
<span class=3D"Apple-tab-span" style=3D"white-space:pre"></span>Title &nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: Validation of Loca=
tions Around a Planned Change<br>
<span class=3D"Apple-tab-span" style=3D"white-space:pre"></span>Author(s) &=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: Brian Rosen<br>
<span class=3D"Apple-tab-span" style=3D"white-space:pre"></span>Filename &n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: draft-rosen-ecrit-lost-planned-ch=
anges-00.txt<br>
<span class=3D"Apple-tab-span" style=3D"white-space:pre"></span>Pages &nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: 8<br>
<span class=3D"Apple-tab-span" style=3D"white-space:pre"></span>Date &nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: 2013-11-04<br=
>
<br>
Abstract:<br>
&nbsp;&nbsp;This document defines an extension to LoST (RFC5222) that allow=
s a<br>
&nbsp;&nbsp;planned change to the data in the LoST server to occur. &nbsp;R=
ecords that<br>
&nbsp;&nbsp;previously were valid will become invalid at a date in the futu=
re,<br>
&nbsp;&nbsp;and new locations will become valid after the date. &nbsp;The e=
xtension<br>
&nbsp;&nbsp;adds two elements to the &lt;findservice&gt; request: a URI to =
be used to<br>
&nbsp;&nbsp;inform the LIS that previously valid locations will be invalid =
after<br>
&nbsp;&nbsp;the planned change date, and add a date which requests the serv=
er to<br>
&nbsp;&nbsp;perform validation as of the date specified.<br>
<br>
<br>
The IETF datatracker status page for this draft is:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-rosen-ecrit-lost-planned-=
changes">https://datatracker.ietf.org/doc/draft-rosen-ecrit-lost-planned-ch=
anges</a><br>
<br>
There's also a htmlized version available at:<br>
http://tools.ietf.org/html/draft-rosen-ecrit-lost-planned-changes-00<br>
<br>
<br>
Please note that it may take a couple of minutes from the time of submissio=
n<br>
until the htmlized version and diff are available at tools.ietf.org.<br>
<br>
Internet-Drafts are also available by anonymous FTP at:<br>
ftp://ftp.ietf.org/internet-drafts/<br>
<br>
_______________________________________________<br>
I-D-Announce mailing list<br>
I-D-Announce@ietf.org<br>
https://www.ietf.org/mailman/listinfo/i-d-announce<br>
Internet-Draft directories: http://www.ietf.org/shadow.html<br>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<br>
</div>
</blockquote>
</div>
<br>
</body>
</html>

--_000_B922BAA51ED34367A0D6BB15B1C25BE0neustarbiz_--

From br@brianrosen.net  Mon Nov  4 10:45:43 2013
Return-Path: <br@brianrosen.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 21F4411E81BC for <ecrit@ietfa.amsl.com>; Mon,  4 Nov 2013 10:45:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.486
X-Spam-Level: 
X-Spam-Status: No, score=-103.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+27703rklxt for <ecrit@ietfa.amsl.com>; Mon,  4 Nov 2013 10:45:38 -0800 (PST)
Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 05D8711E8116 for <ecrit@ietf.org>; Mon,  4 Nov 2013 10:45:27 -0800 (PST)
Received: by mail-qa0-f42.google.com with SMTP id i13so333854qae.8 for <ecrit@ietf.org>; Mon, 04 Nov 2013 10:45:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:references:to :message-id:mime-version; bh=LRASz+ZYCegPpUj3h0C97lBKkViil8gSVzXxAZvMUf4=; b=hG0ZQr2WLVHgGwl8m02mdm279C1QSrTH+kFqaz4wgBUnNnZ4Ac+D4N1ZjkNx31ui9G zUOhxDK2s1MTfwUqf6J3axIFNjV46ZSYyvW2rM0vWFqR1VRDnBRYmJy4lDyM5E5c646T 1Trm/pguXilyB9FAXT0iilrPoYpeQlbWoyQp0aO8B06Zjl3/dAJPaZR4evIweEH/K+A4 2WRtcE80mG+pPgapoZXE77KbevweR70EMYz55SVla1pUEcQPt1xajrF/WMcrkhwWo83p iD0KhOkD4B/H4FQ8aLqLG6+zeHl+Txd5eoWATv4+nqpslJ8qxF5VRQ2XlXQzZLwHhJvM 4oCQ==
X-Gm-Message-State: ALoCoQlH0p1pIvvn0EVX6EMr6k+llHVWhhnR9h8celD4TlKzn38M9sgYgF+GsJMFFO2e+ODPgotV
X-Received: by 10.224.69.69 with SMTP id y5mr24038673qai.53.1383590727369; Mon, 04 Nov 2013 10:45:27 -0800 (PST)
Received: from [192.168.128.255] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id h2sm36921080qaf.10.2013.11.04.10.45.25 for <ecrit@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 10:45:26 -0800 (PST)
From: Brian Rosen <br@brianrosen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F2494B74-AD2C-4CD5-AD17-45B84BCB7243"
Date: Mon, 4 Nov 2013 10:45:21 -0800
References: <20131104182457.10133.83864.idtracker@ietfa.amsl.com>
To: ecrit <ecrit@ietf.org>
Message-Id: <564BB95F-425D-4E20-85FD-AD11EB23F964@brianrosen.net>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
X-Mailer: Apple Mail (2.1816)
Subject: [Ecrit] Fwd: New Version Notification for draft-rosen-ecrit-lost-planned-changes-00.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 04 Nov 2013 18:45:43 -0000

--Apple-Mail=_F2494B74-AD2C-4CD5-AD17-45B84BCB7243
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

This update adds the PUBLISH mechanism for devices that can=92t support =
a server for SUB/NOT.

Brian

Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: New Version Notification for =
draft-rosen-ecrit-lost-planned-changes-00.txt
> Date: November 4, 2013 at 10:24:57 AM PST
> To: Brian Rosen <br@brianrosen.net>
>=20
>=20
> A new version of I-D, draft-rosen-ecrit-lost-planned-changes-00.txt
> has been successfully submitted by Brian Rosen and posted to the
> IETF repository.
>=20
> Filename:	 draft-rosen-ecrit-lost-planned-changes
> Revision:	 00
> Title:		 Validation of Locations Around a Planned Change
> Creation date:	 2013-11-04
> Group:		 Individual Submission
> Number of pages: 8
> URL:             =
http://www.ietf.org/internet-drafts/draft-rosen-ecrit-lost-planned-changes=
-00.txt
> Status:          =
http://datatracker.ietf.org/doc/draft-rosen-ecrit-lost-planned-changes
> Htmlized:        =
http://tools.ietf.org/html/draft-rosen-ecrit-lost-planned-changes-00
>=20
>=20
> Abstract:
>   This document defines an extension to LoST (RFC5222) that allows a
>   planned change to the data in the LoST server to occur.  Records =
that
>   previously were valid will become invalid at a date in the future,
>   and new locations will become valid after the date.  The extension
>   adds two elements to the <findservice> request: a URI to be used to
>   inform the LIS that previously valid locations will be invalid after
>   the planned change date, and add a date which requests the server to
>   perform validation as of the date specified.
>=20
>=20
>=20
>=20
> 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.
>=20
> The IETF Secretariat
>=20


--Apple-Mail=_F2494B74-AD2C-4CD5-AD17-45B84BCB7243
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">This =
update adds the PUBLISH mechanism for devices that can=92t support a =
server for SUB/NOT.<div><br></div><div>Brian<br><div><br><div>Begin =
forwarded message:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; color:rgba(0, =
0, 0, 1.0);"><b>From: </b></span><span =
style=3D"font-family:'Helvetica';"><a =
href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a><br><=
/span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>Subject: =
</b></span><span style=3D"font-family:'Helvetica';"><b>New Version =
Notification for =
draft-rosen-ecrit-lost-planned-changes-00.txt</b><br></span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; color:rgba(0, =
0, 0, 1.0);"><b>Date: </b></span><span =
style=3D"font-family:'Helvetica';">November 4, 2013 at 10:24:57 AM =
PST<br></span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>To: =
</b></span><span style=3D"font-family:'Helvetica';">Brian Rosen &lt;<a =
href=3D"mailto:br@brianrosen.net">br@brianrosen.net</a>&gt;<br></span></di=
v><br><div><br>A new version of I-D, =
draft-rosen-ecrit-lost-planned-changes-00.txt<br>has been successfully =
submitted by Brian Rosen and posted to the<br>IETF =
repository.<br><br>Filename:<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span> =
draft-rosen-ecrit-lost-planned-changes<br>Revision:<span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span> =
00<br>Title:<span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span> Validation of Locations Around a Planned Change<br>Creation =
date:<span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span> =
2013-11-04<br>Group:<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span> Individual Submission<br>Number =
of pages: 8<br>URL: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a=
 =
href=3D"http://www.ietf.org/internet-drafts/draft-rosen-ecrit-lost-planned=
-changes-00.txt">http://www.ietf.org/internet-drafts/draft-rosen-ecrit-los=
t-planned-changes-00.txt</a><br>Status: =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"http://datatracker.ietf.org/doc/draft-rosen-ecrit-lost-planned-cha=
nges">http://datatracker.ietf.org/doc/draft-rosen-ecrit-lost-planned-chang=
es</a><br>Htmlized: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"http://tools.ietf.org/html/draft-rosen-ecrit-lost-planned-changes-=
00">http://tools.ietf.org/html/draft-rosen-ecrit-lost-planned-changes-00</=
a><br><br><br>Abstract:<br> &nbsp;&nbsp;This document defines an =
extension to LoST (RFC5222) that allows a<br> &nbsp;&nbsp;planned change =
to the data in the LoST server to occur. &nbsp;Records that<br> =
&nbsp;&nbsp;previously were valid will become invalid at a date in the =
future,<br> &nbsp;&nbsp;and new locations will become valid after the =
date. &nbsp;The extension<br> &nbsp;&nbsp;adds two elements to the =
&lt;findservice&gt; request: a URI to be used to<br> &nbsp;&nbsp;inform =
the LIS that previously valid locations will be invalid after<br> =
&nbsp;&nbsp;the planned change date, and add a date which requests the =
server to<br> &nbsp;&nbsp;perform validation as of the date =
specified.<br><br><br><br><br>Please note that it may take a couple of =
minutes from the time of submission<br>until the htmlized version and =
diff are available at <a =
href=3D"http://tools.ietf.org">tools.ietf.org</a>.<br><br>The IETF =
Secretariat<br><br></div></blockquote></div><br></div></body></html>=

--Apple-Mail=_F2494B74-AD2C-4CD5-AD17-45B84BCB7243--

From randy@qti.qualcomm.com  Wed Nov  6 10:16:14 2013
Return-Path: <randy@qti.qualcomm.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 87F8011E823B for <ecrit@ietfa.amsl.com>; Wed,  6 Nov 2013 10:16:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.465
X-Spam-Level: 
X-Spam-Status: No, score=-104.465 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9cnxyNQ82w6 for <ecrit@ietfa.amsl.com>; Wed,  6 Nov 2013 10:16:10 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id A06C511E81DC for <ecrit@ietf.org>; Wed,  6 Nov 2013 10:16:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1383761770; x=1415297770; h=message-id:date:to:from:subject:mime-version; bh=gFbptbAnNQBuxW3yEhmSxhl8q+j8y/509S1lREBFY2U=; b=hEbhTyx9lpFljAsbGouAqnE9tb9OtBVTxuittowxp/h4v8rITucCiLi/ i5Pz43F8pS/PoghAnEJF/r7ZTrQkYn/Rz9mIBxBoQszbSkA17n3clunT8 DSNbWwFgk/l7XktvOlZultSXcavwEtcivJ68tOe+QPM6Addg1BD23LYCV o=;
X-IronPort-AV: E=McAfee;i="5400,1158,7251"; a="85384769"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 06 Nov 2013 10:16:10 -0800
X-IronPort-AV: E=McAfee;i="5400,1158,7250"; a="568828796"
Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Nov 2013 10:16:10 -0800
Received: from dhcp-9302.meeting.ietf.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 Nov 2013 10:16:08 -0800
Message-ID: <p06240600cea0355a137a@dhcp-9302.meeting.ietf.org>
X-Mailer: Eudora for Mac OS X
Date: Wed, 6 Nov 2013 10:06:51 -0800
To: <ecrit@ietf.org>
From: Randall Gellens <randy@qti.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [172.30.39.5]
Subject: [Ecrit] Fwd: New Version Notification for draft-gellens-ecrit-car-crash-01.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 06 Nov 2013 18:16:14 -0000

Changes from -00 to -01

    o  Now using 'EmergencyCallData' for purpose parameter values and
       MIME subtypes, in accordance with changes to
       [additional-data-draft]

    o  Added reference to RFC 6443


--- begin forwarded text


To: Randall Gellens <randy@qti.qualcomm.com>, Brian Rosen
	<br@brianrosen.net>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, "Hannes
  Tschofenig" <Hannes.Tschofenig@gmx.net>
From: <internet-drafts@ietf.org>
Subject: New Version Notification for draft-gellens-ecrit-car-crash-01.txt
Date: Wed, 6 Nov 2013 08:43:02 -0800


A new version of I-D, draft-gellens-ecrit-car-crash-01.txt
has been successfully submitted by Randall Gellens and posted to the
IETF repository.

Filename:	 draft-gellens-ecrit-car-crash
Revision:	 01
Title:		 Internet Protocol-based In-Vehicle Emergency Calls
Creation date:	 2013-11-06
Group:		 Individual Submission
Number of pages: 21
URL: 
http://www.ietf.org/internet-drafts/draft-gellens-ecrit-car-crash-01.txt
Status:          http://datatracker.ietf.org/doc/draft-gellens-ecrit-car-crash
Htmlized:        http://tools.ietf.org/html/draft-gellens-ecrit-car-crash-01
Diff: 
http://www.ietf.org/rfcdiff?url2=draft-gellens-ecrit-car-crash-01

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 an 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).

    Profiling and simplifications are possible due to the nature of the
    functionality that is provided in vehicles with the usage of Global
    Satellite Navigation System (GNSS).




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.

The IETF Secretariat

--- end forwarded text


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
A successful tool is used to do something undreamed of by its author.
                                                           --Johnson

From randy@qti.qualcomm.com  Wed Nov  6 10:16:18 2013
Return-Path: <randy@qti.qualcomm.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 6EA8711E823B for <ecrit@ietfa.amsl.com>; Wed,  6 Nov 2013 10:16:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.196
X-Spam-Level: 
X-Spam-Status: No, score=-101.196 tagged_above=-999 required=5 tests=[AWL=-0.897, BAYES_00=-2.599, MANGLED_TOOL=2.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 753FNMUhIdoP for <ecrit@ietfa.amsl.com>; Wed,  6 Nov 2013 10:16:12 -0800 (PST)
Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 043C111E8239 for <ecrit@ietf.org>; Wed,  6 Nov 2013 10:16:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1383761771; x=1415297771; h=message-id:date:to:from:subject:mime-version; bh=h8w3sI8J6Tyt5reBeZuo3nS4nJFTE6V6AlQI0UM+QOg=; b=ajQuRlCp8Q6WJu774Du5tbNYzadkaKJ54+3kQCLlJGR3SH1F71y0WUsG EnWHas6MDeSU/jxAV/lQwtKScU/RDkUqSUrXPemzUekG+xAjn8SOIEMja C4f6aTtPhONFe+3VsoGYfn9K/5DDkNtn1r54QiqY+ZQI8Qr7FYf/bxINZ k=;
X-IronPort-AV: E=McAfee;i="5400,1158,7251"; a="55047422"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 06 Nov 2013 10:16:11 -0800
X-IronPort-AV: E=McAfee;i="5400,1158,7250"; a="544299374"
Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Nov 2013 10:16:11 -0800
Received: from dhcp-9302.meeting.ietf.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 Nov 2013 10:16:10 -0800
Message-ID: <p06240601cea035c12b98@dhcp-9302.meeting.ietf.org>
X-Mailer: Eudora for Mac OS X
Date: Wed, 6 Nov 2013 10:07:35 -0800
To: <ecrit@ietf.org>
From: Randall Gellens <randy@qti.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [172.30.39.5]
Subject: [Ecrit] Fwd: New Version Notification for draft-gellens-ecrit-ecall-01.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 06 Nov 2013 18:16:18 -0000

Changes from -00 to -01

    o  Now using 'EmergencyCallData' for purpose parameter values and
       MIME subtypes, in accordance with changes to
       [additional-data-draft]

    o  Added reference to RFC 6443

--- begin forwarded text


To: Randall Gellens <randy@qti.qualcomm.com>, Hannes Tschofenig
	<hannes.tschofenig@gmx.net>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
From: <internet-drafts@ietf.org>
Subject: New Version Notification for draft-gellens-ecrit-ecall-01.txt
Date: Wed, 6 Nov 2013 09:00:29 -0800


A new version of I-D, draft-gellens-ecrit-ecall-01.txt
has been successfully submitted by Randall Gellens and posted to the
IETF repository.

Filename:	 draft-gellens-ecrit-ecall
Revision:	 01
Title:		 Next-Generation Pan-European eCall
Creation date:	 2013-11-06
Group:		 Individual Submission
Number of pages: 16
URL: 
http://www.ietf.org/internet-drafts/draft-gellens-ecrit-ecall-01.txt
Status:          http://datatracker.ietf.org/doc/draft-gellens-ecrit-ecall
Htmlized:        http://tools.ietf.org/html/draft-gellens-ecrit-ecall-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-gellens-ecrit-ecall-01

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.  eCall deployment is required by 2015 in
    European Union member states, and eCall is also being deployed in
    other regions.  eCall provides an integrated voice path and a
    standardized set of vehicle, sensor (e.g., crash related), and
    location data.  An eCall is recognized and handled as a specialized
    form of emergency call and is routed to a specialized eCall-capable
    Public Safety Answering Point (PSAP) capable of processing the
    vehicle data and trained in handling emergency calls from vehicles.
    Currently, eCall functions over circuit-switched cellular telephony;
    work on next-generation eCall (NG-eCall, sometimes called packet-
    switched eCall or PS-eCall) is now in process, and this document
    assists in that work by describing how to support eCall within the
    IP-based emergency services infrastructure.

    This document also registers a MIME Content Type and an Emergency
    Call Additional Data Block for the eCall vehicle data.




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.

The IETF Secretariat

--- end forwarded text


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Deregulation will be the greatest thing to happen to the airlines
since the jet engine.   -- Richard Ferris, CEO United Airlines, 1976

From christer.holmberg@ericsson.com  Thu Nov 14 16:11:07 2013
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 865EF11E812B for <ecrit@ietfa.amsl.com>; Thu, 14 Nov 2013 16:11:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.575
X-Spam-Level: 
X-Spam-Status: No, score=-5.575 tagged_above=-999 required=5 tests=[AWL=0.673,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsLGbyOQFrgT for <ecrit@ietfa.amsl.com>; Thu, 14 Nov 2013 16:11:01 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7D85011E80DC for <ecrit@ietf.org>; Thu, 14 Nov 2013 16:11:00 -0800 (PST)
X-AuditID: c1b4fb30-b7f228e000003e6c-a5-528566935266
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id AD.70.15980.39665825; Fri, 15 Nov 2013 01:10:59 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.132]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Fri, 15 Nov 2013 01:10:59 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "ecrit@ietf.org" <ecrit@ietf.org>
Thread-Topic: Additional Call Data: Info Package
Thread-Index: Ac7hlsOij6NR7T2TRuS2sC2Tb3Y2Rw==
Date: Fri, 15 Nov 2013 00:10:58 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C519ED4@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C519ED4ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvre7ktNYgg9/P5SymnbzMbNG46Cmr A5PHkiU/mTx2NDxnDmCK4rJJSc3JLEst0rdL4Mo49/4kU8HjyorbZzqYGxg/Z3cxcnJICJhI HGg/zwJhi0lcuLeeDcQWEjjEKPHlcnkXIxeQvYRR4t2U0+xdjBwcbAIWEt3/tEFqRARUJTac WckIEmYWcJNYdzQBJCwsoC3x9FUbC0hYRMBAYv1eZYhqPYnfGz8ygtgsQJ1rtk8Bs3kFfCUu ndnPCmIzAl3w/dQaJhCbWUBc4sPB68wQlwlILNlzHsoWlXj5+B8rhK0ksfbwdhaI+nyJy/v+ skDMFJQ4OfMJywRG4VlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxcie m5iZk15uvokRGB0Ht/w22MG46b7YIUZpDhYlcd4Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEy cXBKNTDaJx/dZqMksohV/4GT+PSdRxpCO7/e2XmLtVt6Tc2aGxMP67ELqCY/L/w8edcxZ5Wo J5IH3JhmHr7S/Ssu2HHRjEX2f5J0BAuuJ1v9v1bQ+tJov0LeYqnm62ZPPhd8YjbubTwzUZxf jJHn8/yqfMH9n+cwi+23npZqf6qQW9X60HNOxo7oX1OUWIozEg21mIuKEwGxtmP7XAIAAA==
Cc: "Rosen, Brian \(Brian.Rosen@neustar.biz\)" <Brian.Rosen@neustar.biz>
Subject: [Ecrit] Additional Call Data: Info Package
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 15 Nov 2013 00:11:07 -0000

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

Hi,

I put together the first version of an Info Package used to send Additional=
 Call Data for an emergency call, using INFO requests.

At this point I have not written a draft, because I think it would fit in d=
raft-rosen-ecrit-addldata-subnot, eventhough we may want to change/remove t=
he "subnot" part in the draft name.

Regards,

Christer

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


5.  Info Package for Additional Call Data



5.1.  General



The Info Package is used to update Additional Call Data related to an emerg=
ency call, as described in [I-D.ietf-ecrit-additional-data].



5.2.  Overal Description



TBD



5.3.  Applicability



The Info Package is only to be used within an emergency call.



5.4.  Info Package Name



The name of the Info Package is: infoAdditionaCallData



5.5.  Info Package Parameters



5.5.1.  General



An Info Package name parameter, maxRate, is defined for the Info Package. T=
he parameter can be inserted by a Public Safety Answering Point (PSAP), in =
the Recv-Info header field of a response the INVITE request establishing th=
e emergency call, to indicate the maximum number of INFO requests, associat=
ed with the Info Package, that can be sent towards the PSAP per second.



5.5.2.  ABNF



maxRate =3D "maxRate" EQUAL (1*2DIGIT ["." 1*10DIGIT])



5.6.  SIP option tags



No SIP option tags are defined for the Info Package.



5.7.  INFO message body parts



Additional Call Data is carried in the message body defined in section XXX.



The MIME type value for the message body is: 'application/emergencyCall.Svc=
Info+xml', defined in section XXX.



The Content Disposition value for the message body, when associated with th=
e Info Package, is "info-package" (see RFC 6086 [XX]).



5.8.  Info Package usage restrictions



No usage restrictions are defined for the Info Package.



5.9.  Rate of INFO requests



A PSAP can indicate the maximum rate for sending INFO requests associated w=
ith the Info Package, using the maxRate Info Package parameter.



In the absence of a maxRate parameter, INFO requests associated with the In=
fo Package MUST NOT be sent more frequently than once every twenty seconds.



5.10.  Security considerations



Security considerations for the Info Package update mechanism are

   identical to those in [I-D.ietf-ecrit-additional-data].


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




--_000_7594FB04B1934943A5C02806D1A2204B1C519ED4ESESSMB209erics_
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";
	mso-fareast-language:EN-US;}
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:"Vain tekstin\00E4 Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;
	mso-fareast-language:EN-US;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML-esimuotoiltu Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.Shkpostityyli17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTML-esimuotoiltuChar
	{mso-style-name:"HTML-esimuotoiltu Char";
	mso-style-priority:99;
	mso-style-link:HTML-esimuotoiltu;
	font-family:"Courier New";
	mso-fareast-language:FI;}
span.VaintekstinChar
	{mso-style-name:"Vain tekstin\00E4 Char";
	mso-style-priority:99;
	mso-style-link:"Vain tekstin\00E4";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 2.0cm 70.85pt 2.0cm;}
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"FI" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi,<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I put together the first versio=
n of an Info Package used to send Additional Call Data for an emergency cal=
l, using INFO requests.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">At this point I have not writte=
n a draft, because I think it would fit in draft-rosen-ecrit-addldata-subno=
t, eventhough we may want to change/remove the &#8220;subnot&#8221; part in=
 the draft name.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Regards,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Christer<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">-------------------------------=
----------------<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">5.&nbsp; Info Package for Additional Call Data<o:p></o:p>=
</span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">5.1.&nbsp; General<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">The Info Package is used to update Additional Call Data r=
elated to an emergency call, as described in [I-D.ietf-ecrit-additional-dat=
a].<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">5.2.&nbsp; Overal Description<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">TBD<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">5.3.&nbsp; Applicability<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">The Info Package is only to be used within an emergency c=
all.<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">5.4.&nbsp; Info Package Name<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">The name of the Info Package is: infoAdditionaCallData<o:=
p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">5.5.&nbsp; Info Package Parameters<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">5.5.1.&nbsp; General<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">An Info Package name parameter, maxRate, is defined for t=
he Info Package. The parameter can be inserted by a Public Safety Answering=
 Point (PSAP), in the Recv-Info header field of
 a response the INVITE request establishing the emergency call, to indicate=
 the maximum number of INFO requests, associated with the Info Package, tha=
t can be sent towards the PSAP per second.<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">5.5.2.&nbsp; ABNF<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<pre><span lang=3D"EN-US">maxRate =3D &quot;maxRate&quot; EQUAL (1*2DIGIT [=
&quot;.&quot; 1*10DIGIT])<o:p></o:p></span></pre>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">5.6.&nbsp; SIP option tags<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">No SIP option tags are defined for the Info Package.<o:p>=
</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">5.7.&nbsp; INFO message body parts<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">Additional Call Data is carried in the message body defin=
ed in section XXX.<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">The MIME type value for the message body is: 'application=
/emergencyCall.SvcInfo&#43;xml', defined in section XXX.<o:p></o:p></span><=
/p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">The Content Disposition value for the message body, when =
associated with the Info Package, is &quot;info-package&quot; (see RFC 6086=
 [XX]).<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">5.8.&nbsp; Info Package usage restrictions<o:p></o:p></sp=
an></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">No usage restrictions are defined for the Info Package.<o=
:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">5.9.&nbsp; Rate of INFO requests<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">A PSAP can indicate the maximum rate for sending INFO req=
uests associated with the Info Package, using the maxRate Info Package para=
meter.<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">In the absence of a maxRate parameter, INFO requests asso=
ciated with the Info Package MUST NOT be sent more frequently than once eve=
ry twenty seconds.<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">5.10.&nbsp; Security considerations<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">Security considerations for the Info Package update mecha=
nism are<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;">&nbsp;&nbsp; identical to those in [I-D.ietf-ecrit-additi=
onal-data].<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">-------------------------------=
----------------<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US" style=3D"font-family:&quot;C=
ourier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
</body>
</html>

--_000_7594FB04B1934943A5C02806D1A2204B1C519ED4ESESSMB209erics_--

From iesg-secretary@ietf.org  Fri Nov 22 09:28:44 2013
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9FF1AE04C; Fri, 22 Nov 2013 09:28:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 HJiD5fwrAljB; Fri, 22 Nov 2013 09:28:42 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1025F1AE013; Fri, 22 Nov 2013 09:28:42 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131122172842.16575.91159.idtracker@ietfa.amsl.com>
Date: Fri, 22 Nov 2013 09:28:42 -0800
Cc: ecrit WG <ecrit@ietf.org>
Subject: [Ecrit] WG Review: Emergency Context Resolution with Internet Technologies (ecrit)
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 22 Nov 2013 17:28:44 -0000

The Emergency Context Resolution with Internet Technologies (ecrit)
working group in the Real-time Applications and Infrastructure Area of
the IETF is undergoing rechartering. The IESG has not made any
determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to
the IESG mailing list (iesg at ietf.org) by 2013-12-02.

Emergency Context Resolution with Internet Technologies (ecrit)
------------------------------------------------
Current Status: Active WG

Chairs:
  Marc Linsner <marc.linsner@cisco.com>
  Roger Marshall <rmarshall@telecomsys.com>

Assigned Area Director:
  Richard Barnes <rlb@ipv.sx>

Mailing list
  Address: ecrit@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/ecrit
  Archive: http://www.ietf.org/mail-archive/web/ecrit/

Charter:

In a number of areas, the public switched telephone network (PSTN) has 
been configured to recognize an explicitly specified number (usually one 
that is short and easily memorized) as a request for emergency services. 

These numbers (e.g., 911, 112) are related to an emergency service 
context and depend on a broad, regional configuration of service contact 
methods and a geographically-constrained approach for service delivery.  
These calls are intended to be delivered to special call centers 
equipped to manage emergency response. Successful delivery of an 
emergency service call within those systems requires an association of 
both the physical location of the originating device  along with 
appropriate call routing to an emergency service center.

Calls placed using Internet technologies do not use the same systems 
mentioned above to achieve those same goals, and the common use of 
overlay networks and tunnels (either as VPNs or for mobility) makes 
meeting these goals even more challenging.  There are, however, Internet 
technologies available to manage location and to perform call routing.
  
This working group has described where and how these mechanisms may be 
used. The group specified how location data and call routing information 
are  used to enable communication between a user and a relevant emergency

response center [RFC6443,RFC6444]. Though the term "call routing" is
used, 
it should be understood that some of the mechanisms described might be
used 
to enable other types of media streams.

Beyond human initiated emergency call request mechanisms, this group will

develop new methods to enable non-human-initiated requests for emergency 
assistance, such as sensor initiated emergency requests.

The working group will also address topics required for the operation of 
emergency calling systems, such as:  authentication of location,
management 
of the service URN namespace, augmented information that could assist 
emergency call takers or responders.

Explicitly outside the scope of this group is the question of pre-
emption or prioritization of emergency services traffic in the network. 
This group is considering emergency services calls which might be made 
by any user of the Internet, as opposed to government or military
services 
that may impose very different authentication and routing requirements.

While this group anticipates a close working relationship with groups 
such as NENA, EENA, 3GPP, and ETSI , any solution presented must be 
general enough to be potentially useful in or across multiple regions or 
jurisdictions, and it must be possible to use without requiring a 
single, central authority.  Further, it must be possible for multiple 
delegations within a jurisdiction to be handled independently, things 
such as call routing for specific emergency types, media types,
language contents, etc.,  may be routed differently depending on 
established policies and availability.

This working group will address privacy and security concerns within its 
documents.



Milestones:
  Done     - Informational RFC containing terminology definitions and the
requirements
  Done     - An Informational document describing the threats and
security considerations
  Done     - A Standards Track RFC describing how to identify a session
set-up request is to an emergency response center
  Done     - A Standards Track RFC describing how to route an emergency
call based on location information
  Done     - An Informational document describing the Mapping Protocol
Architecture
  Done     - Submit 'Location Hiding: Problem Statement and Requirements'
to the IESG for consideration as an Informational RFC.
  Done     - Submit 'Framework for Emergency Calling using Internet
Multimedia' to the IESG for consideration as an Informational RFC.
  Done     - Submit 'Best Current Practice for Communications Services in
support of Emergency Calling' to the IESG for consideration as a BCP
document
  Done     - Submit 'LoST Extension for returning Boundary Information
for Services' to the IESG for consideration as an Experimental RFC
  Done     - Submit 'Synchronizing Location-to-Service Translation (LoST)
Protocol based Service Boundaries and Mapping Elements' to the IESG for
consideration as an Experimental RFC
  Done     - Submit 'Public Safety Answering Point (PSAP) Callbacks' to
the IESG for consideration as an Informational RFC
  Done     - Submit 'Extensions to the Emergency Services Architecture
for dealing with Unauthenticated and Unauthorized Devices' to the IESG
for consideration as a Standards Track RFC
  Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only
Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG
for consideration as an Experimental RFC
  Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for
consideration as an Informational RFC
  Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call
Purposes' to the IESG for consideration as a Standards Track RFC
  Dec 2013 - Submit a draft 'Policy for defining new service-identifying
labels' to the IESG for consideration as BCP
  Dec 2013 -  Submit a draft 'URN For Country Specific Emergency
Services' to the IESG for consideration as a Standards Track RFC
  Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing'
to the IESG for consideration as an Informational RFC



From rg+ietf@qualcomm.com  Fri Nov 22 10:41:37 2013
Return-Path: <rg+ietf@qualcomm.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B001AE206; Fri, 22 Nov 2013 10:41:37 -0800 (PST)
X-Quarantine-ID: <a6zVhUWqVNLH>
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.826
X-Spam-Level: 
X-Spam-Status: No, score=-4.826 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
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 a6zVhUWqVNLH; Fri, 22 Nov 2013 10:41:35 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id E01C31AE1FD; Fri, 22 Nov 2013 10:41:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1385145688; x=1416681688; h=x-ojodefuego:message-id:in-reply-to:references:x-mailer: date:to:from:subject:cc:content-type; bh=hcHOEpaeDPBmWE/kzoj2cMKXne0wE0DPapfL5z3S5qM=; b=X97f5ZWP+B78wy5Tq7x9A+PMp1wpUxpSiJp9uYjtL+8B2pk3hxQ6N3+y HgqPC8izNGDnTjBkCBxd4gfZ7PRxWk11Ugf3TEpQgrMYwE36qQyu9wJBi kI8WDg8KDJL68mfhb14Zqk7KNe32KDMTwaknlLGskacbRZJ8tEfO7ZhST 0=;
X-IronPort-AV: E=McAfee;i="5400,1158,7267"; a="88439991"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 22 Nov 2013 10:41:27 -0800
X-IronPort-AV: E=McAfee;i="5400,1158,7267"; a="576326352"
Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Nov 2013 10:41:27 -0800
Received: from Ironmsg03-L.qualcomm.com (ironmsg03-L.qualcomm.com [172.30.48.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id rAMIfRYr006427; Fri, 22 Nov 2013 10:41:27 -0800
X-IronPort-AV: E=McAfee;i="5400,1158,7267"; a="576326304"
X-ojodefuego: yes
Received: from unknown (HELO [99.111.97.136]) ([10.64.198.132]) by Ironmsg03-L.qualcomm.com with ESMTP; 22 Nov 2013 10:41:26 -0800
Mime-Version: 1.0
Message-Id: <p06240603ceb5559c666b@[99.111.97.136]>
In-Reply-To: <20131122172842.16575.91159.idtracker@ietfa.amsl.com>
References: <20131122172842.16575.91159.idtracker@ietfa.amsl.com>
X-Mailer: Eudora for Mac OS X
Date: Fri, 22 Nov 2013 10:41:25 -0800
To: The IESG <iesg@ietf.org>
From: Randall Gellens <rg+ietf@qualcomm.com>
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
Cc: ecrit WG <ecrit@ietf.org>
Subject: Re: [Ecrit] WG Review: Emergency Context Resolution with Internet Technologies (ecrit)
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 22 Nov 2013 18:41:37 -0000

I support the proposed new charter.


At 9:28 AM -0800 11/22/13, The IESG wrote:

>  The Emergency Context Resolution with Internet Technologies (ecrit)
>  working group in the Real-time Applications and Infrastructure Area of
>  the IETF is undergoing rechartering. The IESG has not made any
>  determination yet. The following draft charter was submitted, and is
>  provided for informational purposes only. Please send your comments to
>  the IESG mailing list (iesg at ietf.org) by 2013-12-02.
>
>  Emergency Context Resolution with Internet Technologies (ecrit)
>  ------------------------------------------------
>  Current Status: Active WG
>
>  Chairs:
>    Marc Linsner <marc.linsner@cisco.com>
>    Roger Marshall <rmarshall@telecomsys.com>
>
>  Assigned Area Director:
>    Richard Barnes <rlb@ipv.sx>
>
>  Mailing list
>    Address: ecrit@ietf.org
>    To Subscribe: https://www.ietf.org/mailman/listinfo/ecrit
>    Archive: http://www.ietf.org/mail-archive/web/ecrit/
>
>  Charter:
>
>  In a number of areas, the public switched telephone network (PSTN) has
>  been configured to recognize an explicitly specified number (usually one
>  that is short and easily memorized) as a request for emergency services.
>
>  These numbers (e.g., 911, 112) are related to an emergency service
>  context and depend on a broad, regional configuration of service contact
>  methods and a geographically-constrained approach for service delivery. 
>  These calls are intended to be delivered to special call centers
>  equipped to manage emergency response. Successful delivery of an
>  emergency service call within those systems requires an association of
>  both the physical location of the originating device  along with
>  appropriate call routing to an emergency service center.
>
>  Calls placed using Internet technologies do not use the same systems
>  mentioned above to achieve those same goals, and the common use of
>  overlay networks and tunnels (either as VPNs or for mobility) makes
>  meeting these goals even more challenging.  There are, however, Internet
>  technologies available to manage location and to perform call routing.
>
>  This working group has described where and how these mechanisms may be
>  used. The group specified how location data and call routing information
>  are  used to enable communication between a user and a relevant emergency
>
>  response center [RFC6443,RFC6444]. Though the term "call routing" is
>  used,
>  it should be understood that some of the mechanisms described might be
>  used
>  to enable other types of media streams.
>
>  Beyond human initiated emergency call request mechanisms, this group will
>
>  develop new methods to enable non-human-initiated requests for emergency
>  assistance, such as sensor initiated emergency requests.
>
>  The working group will also address topics required for the operation of
>  emergency calling systems, such as:  authentication of location,
>  management
>  of the service URN namespace, augmented information that could assist
>  emergency call takers or responders.
>
>  Explicitly outside the scope of this group is the question of pre-
>  emption or prioritization of emergency services traffic in the network.
>  This group is considering emergency services calls which might be made
>  by any user of the Internet, as opposed to government or military
>  services
>  that may impose very different authentication and routing requirements.
>
>  While this group anticipates a close working relationship with groups
>  such as NENA, EENA, 3GPP, and ETSI , any solution presented must be
>  general enough to be potentially useful in or across multiple regions or
>  jurisdictions, and it must be possible to use without requiring a
>  single, central authority.  Further, it must be possible for multiple
>  delegations within a jurisdiction to be handled independently, things
>  such as call routing for specific emergency types, media types,
>  language contents, etc.,  may be routed differently depending on
>  established policies and availability.
>
>  This working group will address privacy and security concerns within its
>  documents.
>
>
>
>  Milestones:
>    Done     - Informational RFC containing terminology definitions and the
>  requirements
>    Done     - An Informational document describing the threats and
>  security considerations
>    Done     - A Standards Track RFC describing how to identify a session
>  set-up request is to an emergency response center
>    Done     - A Standards Track RFC describing how to route an emergency
>  call based on location information
>    Done     - An Informational document describing the Mapping Protocol
>  Architecture
>    Done     - Submit 'Location Hiding: Problem Statement and Requirements'
>  to the IESG for consideration as an Informational RFC.
>    Done     - Submit 'Framework for Emergency Calling using Internet
>  Multimedia' to the IESG for consideration as an Informational RFC.
>    Done     - Submit 'Best Current Practice for Communications Services in
>  support of Emergency Calling' to the IESG for consideration as a BCP
>  document
>    Done     - Submit 'LoST Extension for returning Boundary Information
>  for Services' to the IESG for consideration as an Experimental RFC
>    Done     - Submit 'Synchronizing Location-to-Service Translation (LoST)
>  Protocol based Service Boundaries and Mapping Elements' to the IESG for
>  consideration as an Experimental RFC
>    Done     - Submit 'Public Safety Answering Point (PSAP) Callbacks' to
>  the IESG for consideration as an Informational RFC
>    Done     - Submit 'Extensions to the Emergency Services Architecture
>  for dealing with Unauthenticated and Unauthorized Devices' to the IESG
>  for consideration as a Standards Track RFC
>    Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only
>  Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG
>  for consideration as an Experimental RFC
>    Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for
>  consideration as an Informational RFC
>    Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call
>  Purposes' to the IESG for consideration as a Standards Track RFC
>    Dec 2013 - Submit a draft 'Policy for defining new service-identifying
>  labels' to the IESG for consideration as BCP
>    Dec 2013 -  Submit a draft 'URN For Country Specific Emergency
>  Services' to the IESG for consideration as a Standards Track RFC
>    Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing'
>  to the IESG for consideration as an Informational RFC
>
>
>  _______________________________________________
>  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: ---------------
I never travel without my diary.  One should always have something
sensational to read on the train.
    --Oscar Wilde

From ban.albakri@gmail.com  Fri Nov 22 11:28:31 2013
Return-Path: <ban.albakri@gmail.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244DA1AE042 for <ecrit@ietfa.amsl.com>; Fri, 22 Nov 2013 11:28:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.301
X-Spam-Level: 
X-Spam-Status: No, score=0.301 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, MANGLED_TOOL=2.3, SPF_PASS=-0.001] autolearn=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 bUGrYsLdpSnH for <ecrit@ietfa.amsl.com>; Fri, 22 Nov 2013 11:28:29 -0800 (PST)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id EF2EA1ADFCE for <ecrit@ietf.org>; Fri, 22 Nov 2013 11:28:28 -0800 (PST)
Received: by mail-we0-f182.google.com with SMTP id q59so1605732wes.13 for <ecrit@ietf.org>; Fri, 22 Nov 2013 11:28:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Zz/qaIT26fYvj8mKMJjd/64mGdwalYI0VB3/3EqcfiM=; b=fmX4sdUmr36I9QllzAqg8iNNJQSEEpAhe/2VVEnKJFsRUUVSEkpqsmcpVzkiCy2hQ+ N495/24K1+YGVojmpQwYmjN68thBt8jDBCmI5SQwCPUmzqVTwBPqx4xJ9tbr3ltvSlLy uv/1U1+uanQl+b2VEvbD1cDa4zHQlm+987jSj0mE2KFeHX0S1KC7IyVyjYdhjuYMphY0 SvpVdNJFXe6mld+5JGjs9elHQenn8/DzEY9ljc4PJahkMi9ETEoXQpcrEe7iOHKdWDhV 6BEkEZxxzw/3nI5lpCGhkIG4nGnv7A9CzCUerO3IvzpLR/AR/qI0d+lZc+5qKXolfjpt TuEg==
MIME-Version: 1.0
X-Received: by 10.180.12.179 with SMTP id z19mr3983704wib.24.1385148501163; Fri, 22 Nov 2013 11:28:21 -0800 (PST)
Received: by 10.216.120.70 with HTTP; Fri, 22 Nov 2013 11:28:21 -0800 (PST)
In-Reply-To: <p06240601cea035c12b98@dhcp-9302.meeting.ietf.org>
References: <p06240601cea035c12b98@dhcp-9302.meeting.ietf.org>
Date: Fri, 22 Nov 2013 20:28:21 +0100
Message-ID: <CAKH43SeYKza07XfD5Pss5L1_Ps0KHBfF0VdqyKEGoG3cJeZnKw@mail.gmail.com>
From: Ban Al-Bakri <ban.albakri@gmail.com>
To: Randall Gellens <randy@qti.qualcomm.com>, ecrit@ietf.org
Content-Type: multipart/alternative; boundary=001a11c3533a5f836104ebc90471
Subject: Re: [Ecrit] Fwd: New Version Notification for draft-gellens-ecrit-ecall-01.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 22 Nov 2013 19:28:31 -0000

--001a11c3533a5f836104ebc90471
Content-Type: text/plain; charset=ISO-8859-1

Dear All, Randal,

Thank you for providing this draft.

I would like to support the working group adoption of the eCall draft.

Some issues of eCall are still under discussion in ETSI-STF456, as a
consequence changes to the eCall draft may need to be taken into
consideration.

Thank you,

Kind regards,

Ban Al-Bakri
/ETSI-STF456



On 6 November 2013 19:07, Randall Gellens <randy@qti.qualcomm.com> wrote:

> Changes from -00 to -01
>
>    o  Now using 'EmergencyCallData' for purpose parameter values and
>       MIME subtypes, in accordance with changes to
>       [additional-data-draft]
>
>    o  Added reference to RFC 6443
>
> --- begin forwarded text
>
>
> To: Randall Gellens <randy@qti.qualcomm.com>, Hannes Tschofenig
>         <hannes.tschofenig@gmx.net>, Hannes Tschofenig <
> Hannes.Tschofenig@gmx.net>
> From: <internet-drafts@ietf.org>
> Subject: New Version Notification for draft-gellens-ecrit-ecall-01.txt
> Date: Wed, 6 Nov 2013 09:00:29 -0800
>
>
> A new version of I-D, draft-gellens-ecrit-ecall-01.txt
> has been successfully submitted by Randall Gellens and posted to the
> IETF repository.
>
> Filename:        draft-gellens-ecrit-ecall
> Revision:        01
> Title:           Next-Generation Pan-European eCall
> Creation date:   2013-11-06
> Group:           Individual Submission
> Number of pages: 16
> URL: http://www.ietf.org/internet-drafts/draft-gellens-ecrit-ecall-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-gellens-ecrit-ecall
> Htmlized:        http://tools.ietf.org/html/draft-gellens-ecrit-ecall-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-gellens-ecrit-
> ecall-01
>
> 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.  eCall deployment is required by 2015 in
>    European Union member states, and eCall is also being deployed in
>    other regions.  eCall provides an integrated voice path and a
>    standardized set of vehicle, sensor (e.g., crash related), and
>    location data.  An eCall is recognized and handled as a specialized
>    form of emergency call and is routed to a specialized eCall-capable
>    Public Safety Answering Point (PSAP) capable of processing the
>    vehicle data and trained in handling emergency calls from vehicles.
>    Currently, eCall functions over circuit-switched cellular telephony;
>    work on next-generation eCall (NG-eCall, sometimes called packet-
>    switched eCall or PS-eCall) is now in process, and this document
>    assists in that work by describing how to support eCall within the
>    IP-based emergency services infrastructure.
>
>    This document also registers a MIME Content Type and an Emergency
>    Call Additional Data Block for the eCall vehicle data.
>
>
>
>
> 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.
>
> The IETF Secretariat
>
> --- end forwarded text
>
>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> Deregulation will be the greatest thing to happen to the airlines
> since the jet engine.   -- Richard Ferris, CEO United Airlines, 1976
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>

--001a11c3533a5f836104ebc90471
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Dear All, Randal,<div><br></div>Thank you for providing th=
is draft.<br><br>I would like to support the working group adoption of the =
eCall draft.<br><br>Some issues of eCall are still under discussion in ETSI=
-STF456, as a consequence changes to the eCall draft may need to be taken i=
nto consideration.<div>
<br></div><div>Thank you,</div><div><br></div><div>Kind regards,</div><div>=
<br></div><div>Ban Al-Bakri</div><div>/ETSI-STF456<br><br><div class=3D"gma=
il_extra"><br><br><div class=3D"gmail_quote">On 6 November 2013 19:07, Rand=
all Gellens <span dir=3D"ltr">&lt;<a href=3D"mailto:randy@qti.qualcomm.com"=
 target=3D"_blank">randy@qti.qualcomm.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Changes from -00 to -01<br>
<br>
=A0 =A0o =A0Now using &#39;EmergencyCallData&#39; for purpose parameter val=
ues and<br>
=A0 =A0 =A0 MIME subtypes, in accordance with changes to<br>
=A0 =A0 =A0 [additional-data-draft]<br>
<br>
=A0 =A0o =A0Added reference to RFC 6443<br>
<br>
--- begin forwarded text<br>
<br>
<br>
To: Randall Gellens &lt;<a href=3D"mailto:randy@qti.qualcomm.com" target=3D=
"_blank">randy@qti.qualcomm.com</a>&gt;, Hannes Tschofenig<br>
=A0 =A0 =A0 =A0 &lt;<a href=3D"mailto:hannes.tschofenig@gmx.net" target=3D"=
_blank">hannes.tschofenig@gmx.net</a>&gt;, Hannes Tschofenig &lt;<a href=3D=
"mailto:Hannes.Tschofenig@gmx.net" target=3D"_blank">Hannes.Tschofenig@gmx.=
net</a>&gt;<br>

From: &lt;<a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">int=
ernet-drafts@ietf.org</a>&gt;<br>
Subject: New Version Notification for draft-gellens-ecrit-ecall-01.<u></u>t=
xt<br>
Date: Wed, 6 Nov 2013 09:00:29 -0800<br>
<br>
<br>
A new version of I-D, draft-gellens-ecrit-ecall-01.<u></u>txt<br>
has been successfully submitted by Randall Gellens and posted to the<br>
IETF repository.<br>
<br>
Filename: =A0 =A0 =A0 =A0draft-gellens-ecrit-ecall<br>
Revision: =A0 =A0 =A0 =A001<br>
Title: =A0 =A0 =A0 =A0 =A0 Next-Generation Pan-European eCall<br>
Creation date: =A0 2013-11-06<br>
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission<br>
Number of pages: 16<br>
URL: <a href=3D"http://www.ietf.org/internet-drafts/draft-gellens-ecrit-eca=
ll-01.txt" target=3D"_blank">http://www.ietf.org/internet-<u></u>drafts/dra=
ft-gellens-ecrit-<u></u>ecall-01.txt</a><br>
Status: =A0 =A0 =A0 =A0 =A0<a href=3D"http://datatracker.ietf.org/doc/draft=
-gellens-ecrit-ecall" target=3D"_blank">http://datatracker.ietf.org/<u></u>=
doc/draft-gellens-ecrit-ecall</a><br>
Htmlized: =A0 =A0 =A0 =A0<a href=3D"http://tools.ietf.org/html/draft-gellen=
s-ecrit-ecall-01" target=3D"_blank">http://tools.ietf.org/html/<u></u>draft=
-gellens-ecrit-ecall-01</a><br>
Diff: =A0 =A0 =A0 =A0 =A0 =A0<a href=3D"http://www.ietf.org/rfcdiff?url2=3D=
draft-gellens-ecrit-ecall-01" target=3D"_blank">http://www.ietf.org/rfcdiff=
?<u></u>url2=3Ddraft-gellens-ecrit-<u></u>ecall-01</a><br>
<br>
Abstract:<br>
=A0 =A0This document describes how to use IP-based emergency services<br>
=A0 =A0mechanisms to support the next generation of the Pan European in-<br=
>
=A0 =A0vehicle emergency call service defined under the eSafety initiative<=
br>
=A0 =A0of the European Commission (generally referred to as &quot;eCall&quo=
t;). eCall<br>
=A0 =A0is a standardized and mandated system for a special form of emergenc=
y<br>
=A0 =A0calls placed by vehicles. =A0eCall deployment is required by 2015 in=
<br>
=A0 =A0European Union member states, and eCall is also being deployed in<br=
>
=A0 =A0other regions. =A0eCall provides an integrated voice path and a<br>
=A0 =A0standardized set of vehicle, sensor (e.g., crash related), and<br>
=A0 =A0location data. =A0An eCall is recognized and handled as a specialize=
d<br>
=A0 =A0form of emergency call and is routed to a specialized eCall-capable<=
br>
=A0 =A0Public Safety Answering Point (PSAP) capable of processing the<br>
=A0 =A0vehicle data and trained in handling emergency calls from vehicles.<=
br>
=A0 =A0Currently, eCall functions over circuit-switched cellular telephony;=
<br>
=A0 =A0work on next-generation eCall (NG-eCall, sometimes called packet-<br=
>
=A0 =A0switched eCall or PS-eCall) is now in process, and this document<br>
=A0 =A0assists in that work by describing how to support eCall within the<b=
r>
=A0 =A0IP-based emergency services infrastructure.<br>
<br>
=A0 =A0This document also registers a MIME Content Type and an Emergency<br=
>
=A0 =A0Call Additional Data Block for the eCall vehicle data.<br>
<br>
<br>
<br>
<br>
Please note that it may take a couple of minutes from the time of submissio=
n<br>
until the htmlized version and diff are available at <a href=3D"http://tool=
s.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br>
<br>
The IETF Secretariat<br>
<br>
--- end forwarded text<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
<br>
-- <br>
Randall Gellens<br>
Opinions are personal; =A0 =A0facts are suspect; =A0 =A0I speak for myself =
only<br>
-------------- Randomly selected tag: ---------------<br>
Deregulation will be the greatest thing to happen to the airlines<br>
since the jet engine. =A0 -- Richard Ferris, CEO United Airlines, 1976<br>
______________________________<u></u>_________________<br>
Ecrit mailing list<br>
<a href=3D"mailto:Ecrit@ietf.org" target=3D"_blank">Ecrit@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/ecrit" target=3D"_blank">h=
ttps://www.ietf.org/mailman/<u></u>listinfo/ecrit</a><br>
</font></span></blockquote></div><br></div></div></div>

--001a11c3533a5f836104ebc90471--

From rlb@ipv.sx  Fri Nov 22 13:58:18 2013
Return-Path: <rlb@ipv.sx>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3297B1AE23B for <ecrit@ietfa.amsl.com>; Fri, 22 Nov 2013 13:58:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 lS06VVPInA4f for <ecrit@ietfa.amsl.com>; Fri, 22 Nov 2013 13:58:17 -0800 (PST)
Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA9C1ADFF3 for <ecrit@ietf.org>; Fri, 22 Nov 2013 13:58:17 -0800 (PST)
Received: by mail-ob0-f177.google.com with SMTP id va2so1931770obc.36 for <ecrit@ietf.org>; Fri, 22 Nov 2013 13:58:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=6NZkKI2vue5giRjvpvggyX4VXxiIbIy6MStrJU9dSac=; b=X2Yync+FkPAsTw1ttnE7nh1lvKeKyTENweCuxA3n7dbNnODiQjYuNLURsFFQ9okFYK 59K/qy7ptBrmZvneAmgh5Vk0GjSfd7UY3zFSldpJCC0OwWbZD2Zl3LKils8O7A3KPgxv QP3A8qto4HQDun+pCP2SXGe1CDN/NXoEWmh0ushT6zCDlOe7y7u0kg3GZgnYkW5eYRTU n90JZ17yI3W1Tre/SfVHE5MyMYBzGZbeevmdIxaewoIQ3ShEjFbZEtpAFysf9ykgHDtu XC4/ttVQ+tfqDj+m6JTNOS6wTZ3FgltaS/6m9YJ2bJavT4t/JciecqavxLjXALj+R5gy UTPQ==
X-Gm-Message-State: ALoCoQlBZb/jfxKyvWS6U7wFSffWhfMQuMZkjy8ozWQBLFmjwiAR5+vpRuBElkMdh0zeojSYuqKl
MIME-Version: 1.0
X-Received: by 10.60.70.134 with SMTP id m6mr12485995oeu.14.1385157489773; Fri, 22 Nov 2013 13:58:09 -0800 (PST)
Received: by 10.60.31.74 with HTTP; Fri, 22 Nov 2013 13:58:09 -0800 (PST)
Date: Fri, 22 Nov 2013 16:58:09 -0500
Message-ID: <CAL02cgSs0MUVAEN5FRLeERXGFru59XZ3gdtUHe0HS+LppRz0jQ@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: draft-ietf-ecrit-country-emg-urn@tools.ietf.org,  "ecrit-chairs@tools.ietf.org" <ecrit-chairs@tools.ietf.org>, "ecrit@ietf.org" <ecrit@ietf.org>
Content-Type: multipart/alternative; boundary=001a1133458e22e0c804ebcb1c72
Subject: [Ecrit] AD review of draft-ietf-ecrit-country-emg-urn-01
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 22 Nov 2013 21:58:18 -0000

--001a1133458e22e0c804ebcb1c72
Content-Type: text/plain; charset=ISO-8859-1

I have reviewed this draft in preparation for IETF LC, and think it's ready
to go.  Thanks to the authors for a clear and concise specification.
--Richard

--001a1133458e22e0c804ebcb1c72
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I have reviewed this draft in preparation for IETF LC=
, and think it&#39;s ready to go.=A0 Thanks to the authors for a clear and =
concise specification.=A0 <br></div>--Richard<br></div>

--001a1133458e22e0c804ebcb1c72--

From iesg-secretary@ietf.org  Fri Nov 22 14:05:15 2013
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4ED1AE19F; Fri, 22 Nov 2013 14:05:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 Cwa_w24hQ6tR; Fri, 22 Nov 2013 14:05:13 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B235E1AE121; Fri, 22 Nov 2013 14:05:13 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Sender: <iesg-secretary@ietf.org>
Message-ID: <20131122220513.31134.48229.idtracker@ietfa.amsl.com>
Date: Fri, 22 Nov 2013 14:05:13 -0800
Cc: ecrit@ietf.org
Subject: [Ecrit] Last Call: <draft-ietf-ecrit-country-emg-urn-01.txt> (URN For Country Specific Emergency Services) to Proposed Standard
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 22 Nov 2013 22:05:15 -0000

The IESG has received a request from the Emergency Context Resolution
with Internet Technologies WG (ecrit) to consider the following document:
- 'URN For Country Specific Emergency Services'
  <draft-ietf-ecrit-country-emg-urn-01.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-12-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document updates section 4.2 of RFC 5031, in order to allow the
   registration of service URNs with the 'sos' service type for
   emergency services that, at the time of registration, are offered in
   one country only.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ecrit-country-emg-urn/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ecrit-country-emg-urn/ballot/


No IPR declarations have been submitted directly on this I-D.



From internet-drafts@ietf.org  Tue Nov 26 09:01:13 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0841ADF6E; Tue, 26 Nov 2013 09:01:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 qhkm6HYda2zK; Tue, 26 Nov 2013 09:01:12 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2401A1F78; Tue, 26 Nov 2013 09:01:12 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131126170112.22365.11031.idtracker@ietfa.amsl.com>
Date: Tue, 26 Nov 2013 09:01:12 -0800
Cc: ecrit@ietf.org
Subject: [Ecrit] I-D Action: draft-ietf-ecrit-service-urn-policy-03.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Tue, 26 Nov 2013 17:01:13 -0000

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 Interne=
t Technologies Working Group of the IETF.

	Title           : Policy for defining new service-identifying labels
	Author(s)       : Andrea G. Forte
                          Henning Schulzrinne
	Filename        : draft-ietf-ecrit-service-urn-policy-03.txt
	Pages           : 5
	Date            : 2013-11-26

Abstract:
   In order to provide location-based services, descriptive terms for
   services need to be defined.  This document updates the policy for
   defining new service-identifying labels.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ecrit-service-urn-policy-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-service-urn-policy-03


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 forte@att.com  Tue Nov 26 09:13:16 2013
Return-Path: <forte@att.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6225D1ADF26; Tue, 26 Nov 2013 09:13:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level: 
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 MQCCHlnHLtVr; Tue, 26 Nov 2013 09:13:13 -0800 (PST)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 73EEA1ADF30; Tue, 26 Nov 2013 09:13:13 -0800 (PST)
Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 9a6d4925.0.983754.00-439.2776515.nbfkord-smmo05.seg.att.com (envelope-from <forte@att.com>);  Tue, 26 Nov 2013 17:13:13 +0000 (UTC)
X-MXL-Hash: 5294d6a95ac7bf9b-5d40c7496103bbe789bc99355e097b3b33fc8036
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 rAQHDCXl028138; Tue, 26 Nov 2013 12:13:12 -0500
Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rAQHD5Hf028040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Nov 2013 12:13:10 -0500
Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (MISOUT7MSGHUB9C.itservices.sbc.com [144.151.223.82]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 26 Nov 2013 17:12:50 GMT
Received: from MISOUT7MSGUSR9E.ITServices.sbc.com ([144.151.223.57]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.03.0158.001; Tue, 26 Nov 2013 12:12:50 -0500
From: "FORTE, ANDREA G" <forte@att.com>
To: "internet-drafts@ietf.org" <internet-drafts@ietf.org>, "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Thread-Topic: [Ecrit] I-D Action: draft-ietf-ecrit-service-urn-policy-03.txt
Thread-Index: AQHO6skl7ih1wsldpUW6qkHWetAfqZo3v/gA
Date: Tue, 26 Nov 2013 17:12:49 +0000
Message-ID: <CEBA3E5E.1CB99%af199p@att.com>
In-Reply-To: <20131126170112.22365.11031.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [151.109.27.216]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B33EFBCFE1C3154E80D51F3DCE08CE64@LOCAL>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <forte@att.com>
X-SOURCE-IP: [144.160.229.24]
X-AnalysisOut: [v=2.0 cv=QpHpKyOd c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a]
X-AnalysisOut: [=mrsoY93V3OoA:10 a=aDA-NTSHT84A:10 a=ofMgfj31e3cA:10 a=bMb]
X-AnalysisOut: [UTsDMyIwA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpK]
X-AnalysisOut: [OAAAA:8 a=8IVdUA6upSAA:10 a=48vgC7mUAAAA:8 a=QH5x2ri6zyo86]
X-AnalysisOut: [PsRxgcA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10]
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-service-urn-policy-03.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 26 Nov 2013 17:13:16 -0000

Hi all,

I just posted a new version of the draft with some minor corrections and a
few open issues I would like the WG to address.

Currently we have three open issues (and a corresponding "NOTE" paragraph
in the draft for each one of those).

1. Have we agreed to allow private namespaces such as urn:nena in this
document? If so, please take a look at Section 3 of the draft and let me
know if the writing is sufficient.
2. If we allow private namespaces, should Section 4 apply only to the
public namespace domain or do we still want to provide some general
guidelines for private namespaces as well?
3. When we last discussed this document, there were suggestions on
allowing external non-IETF documents/templates to be submitted to the
expert for review. Should we have some requirements about this document in
Section 5? Any specific suggestions on the direction to follow?

Regards,
-- Andrea




On 11/26/13 12:01 PM, "internet-drafts@ietf.org"
<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 Working Group of the IETF.
>
>	Title           : Policy for defining new service-identifying labels
>	Author(s)       : Andrea G. Forte
>                          Henning Schulzrinne
>	Filename        : draft-ietf-ecrit-service-urn-policy-03.txt
>	Pages           : 5
>	Date            : 2013-11-26
>
>Abstract:
>   In order to provide location-based services, descriptive terms for
>   services need to be defined.  This document updates the policy for
>   defining new service-identifying labels.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-ecrit-service-urn-policy
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-ecrit-service-urn-policy-03
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-service-urn-policy-03
>
>
>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