Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - ISSUE 7

Ivo Sedlacek <> Thu, 03 November 2016 22:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AFFD12986E for <>; Thu, 3 Nov 2016 15:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I68eFxIz-j76 for <>; Thu, 3 Nov 2016 15:06:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2490F129861 for <>; Thu, 3 Nov 2016 15:06:52 -0700 (PDT)
X-AuditID: c1b4fb3a-45dfe700000070a2-49-581bb4fa9882
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 9B.AF.28834.AF4BB185; Thu, 3 Nov 2016 23:06:51 +0100 (CET)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 3 Nov 2016 23:06:49 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=enQ/b8GuI3mqL9ntpgP4JzyQW/wekEpbgDjnTU+t37g=; b=m+EdNwfi5wvFHVmxVGuE/D1f8DIKtWe74u/mnnxCtvlqDDg/3RZucmj0w2zoCUCPSlsDUv5vx4bZ2USzAFjnGyhBurn79DLeHyo8vc1z9IwmHah/UpEZkORHMoLFVA3EeGPXQxF5HQWvEUIeSdYwgcLlZO1Jl9cfDgsTKG12vSI=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.1; Thu, 3 Nov 2016 22:06:48 +0000
Received: from ([]) by ([]) with mapi id 15.01.0707.004; Thu, 3 Nov 2016 22:06:48 +0000
From: Ivo Sedlacek <>
To: Randall Gellens <>, Az Mankin <>
Thread-Topic: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - ISSUE 7
Thread-Index: AQHSM47BSesWv686Q3CGsB9ygk2d86DDtQ/wgABgXoCAADLCXoABFUxwgACrVACAAWjqyoAAXmVQ
Date: Thu, 3 Nov 2016 22:06:48 +0000
Message-ID: <>
References: <p06240600d43d18f64b41@> <> <p06240601d43e60ba377e@> <> <> <> <p06240601d4410f4338fa@[]>
In-Reply-To: <p06240601d4410f4338fa@[]>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-office365-filtering-correlation-id: c951ec39-d00e-42c9-6a1d-08d40435b54f
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2468; 7:vyVGznHt/ho8Zt79femJ9IAtKV4wXJ4tJ9FrxWmg6s2l2JYDrCxhg+F0TRc2Whto3OFeQAYYUz4wD108cCS0bZxq//HcPfEOQwLDGs67HMjXV9BRRuTOWLWam/M7vupURTT3hZopuwSCXRObABWzB2iUXMyLdh3l/r3SCNMJcVoAwD/IPDZEmNG85FiwVcoKFua9mXtISvdE5Pe66jbSUWlV1TIKXqa3W4aVmKiS39i4vuizwWtl3/k5aFo59le5dsk3a17go1tJ9ysFtSUzxfIunMYS+1mPqfnqSCAHtAcLym6zRaYzQHfPspWcl0IM5nFqPgddmG4sCkiXNd27VJXVzs3ApU/tMJHB8qXHJYE=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0701MB2468;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AM5PR0701MB2468; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2468;
x-forefront-prvs: 011579F31F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(5403001)(199003)(189002)(76176999)(74316002)(11100500001)(81166006)(5890100001)(33656002)(8676002)(7846002)(92566002)(106116001)(81156014)(2900100001)(105586002)(106356001)(87936001)(586003)(305945005)(7736002)(189998001)(5002640100001)(3660700001)(7696004)(97736004)(5660300001)(3280700002)(230783001)(5001770100001)(122556002)(4326007)(93886004)(8936002)(76576001)(2906002)(77096005)(9686002)(102836003)(66066001)(50986999)(68736007)(86362001)(3846002)(54356999)(6116002)(101416001)(10400500002)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2468;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2016 22:06:48.5569 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2468
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85m8fh6HVpe9pEcFSImqZErJQuflpEoBSlIunKk4o6ZcdE hUotzQzxbjm01FaapMSaqHjJW5kWS1DIvFTmHTOtEBVTc3sN+vZ7/v/neZ8LL0tLdAIZG6mJ 57QadbRCKGJKAhocD64b5QGHGsqclE+KmihlauWUQFn9ol2gXJnJQicZ1cbiEqVq0o1ZqfT6 NUpVPzrB+DFBIp8wLjoygdN6HA8VRSxmdKE4nWNiaUkxlYJqpFnImgV8GIaG++gsJGIluA7B 5uA8RYIeBJm1C4w5YHA2DQWpCztOKQXjpl6GBO8Q5KZ/ZMyPCbE75Bm7BWa2w/6Qff/7dgXL 0vgM1L7aa5Z3YxW8NdxhSMppGFvLpwgHQdufVmRmBu+DbylpQjOLcSh0FBXuzGegYflNlqXY envw/pFCSzHCe2Cl77mFaSyF4clHFFkOg77lA03YHuYmNgUkPxi27v0WEN0JctJzrAifheWR BmRuBriShturPYgYKpg2tVuWARwLGVViIrtAZreOIvktCBoHdAwxHKC6d0pIDJMACrpmLetI MAdVtemInEIGY4N3US5y0f03OGE3KG/+JSTsCk8r5mmd5Rq20FsyyZQjpgbZ8xzPx4R7eblz 2sgrPB+rcddw8Qa0/WM6jOvHGlHHzKlOhFmksBEv+ckDJAJ1Ap8U04mApRV24h+GbUkcpk5K 5rSxIdpr0RzfieQso5CKjzz7clGCw9XxXBTHxXHafy7FWstSkO3y5+kD+gs+gXzgquGc78PM rRsnKo8mz/Wed7u86u2MEmZV8Mn/urZu1Nu3qLl5v6Znrv7le11w4aKp31NG35p3H/g5PWEc 3yXKn8krkD6+lCQbSpxs9W4rq/WoKE+PujklSfN9IG/X00ZTTPBXh6uvVSHFNl1Qo3RuLXYt 2FAwfITa04XW8uq/rodryS0DAAA=
Archived-At: <>
Cc: "" <>
Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - ISSUE 7
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Nov 2016 22:06:56 -0000


I identified a technical problem ("attach X to SIP message" is not defined) during WGLC. 

You did not solve the technical problem during WGLC.

Paul's mail from 1st Nov somehow confirms that there can be different interpretations and something needs to be done ("It needs to be defined in detail for each case.").

I proposed a possible solution in the updated draft.

You do not like the solution but have not proposed any other solution till now.

The technical problem is still unresolved.

I think I have done my duty and it is time for chairs to settle what to do.

Now in details to your answers:

> >  1) rfc7852 defines "conveying" of data (not "attaching" data):
> >  -------------------
> >     When an emergency call is sent to a Public Safety Answering Point
> >     (PSAP), the originating device, the access network provider to which
> >     the device is connected, and all service providers in the path of the
> >     call have information about the call, the caller, or the location,
> >     which is helpful for the PSAP to have in handling the emergency.
> >     This document describes data structures and mechanisms to **convey such
> >     data** to the PSAP.  The intent is that every emergency call carry as
> >     much of the information described here as possible using the
> >     mechanisms described here.
> >
> >     The mechanisms permit the data to be **conveyed** by reference (as an
> >     external resource) or by value (within the body of a SIP message or a
> >     location object).  This follows the tradition of prior emergency
> >     services standardization work where data can be conveyed by value
> >     within the call signaling (i.e., in the body of the SIP message) or
> >     by reference.
> >  -------------------
> >  so I use "convey" when introducing rfc7852 in eCall draft.
> RFC 7852 discusses equally sending data with the call and sending a reference 
> to data that is available externally, hence the use of the neutral term 
> "conveyance."  I think using "conveyance" in the eCall draft would be less 
> well understood by the average reader than using "attach."  The term "attach" 
> seems pretty generally well understood, and the current language in the draft 
> makes it very clear exactly what steps are performed.

"attach X to SIP message" is NOT defined anywhere and thus the standard is NOT clear.

The nearest interpretation of "attach X to SIP message" is "include a body part containing X with Content-Disposition: attachment in SIP message", which does not work with the draft.

> >  Moreover, given that rfc7852 does not use "attach" data, eCall draft 
> > should be able to live without "attach" data too.
> >
> >  2) I *think* the intention of "attach" in the draft is to refer to 
> > "block transmitted by value" as described in rfc7852 section 6.1 the 
> > last paragraph 1st sentence:
> >  -------------------
> >     When blocks are transmitted by value, the 'purpose' parameter in a
> >     Call-Info header field identifies the data, and the CID URL points to
> >     the data block in the body (which has a matching Content-ID body part
> >     header field).
> >  -------------------
> >  So I use "block transmitted by value" everywhere in eCall draft with 
> > exception identified in 3) below.
> That seems more confusing to use in the eCall draft, since eCall data is not 
> transmitted by reference.

"block transmitted by value" is defined in rfc7852. How can it be confusing to use that term together with referencing rfc7852???

"attach X to SIP message" is NOT defined anywhere.

Can usage of a defined term be more confusing than usage of an undefined term???

Kind regards