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

Christer Holmberg <> Fri, 04 November 2016 09:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 335ED12963F for <>; Fri, 4 Nov 2016 02:12:16 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hn-1sJapXt0i for <>; Fri, 4 Nov 2016 02:12:14 -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 0C937129417 for <>; Fri, 4 Nov 2016 02:12:13 -0700 (PDT)
X-AuditID: c1b4fb25-953ff70000001e3e-f3-581c50ebea99
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id B6.AD.07742.BE05C185; Fri, 4 Nov 2016 10:12:12 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Fri, 4 Nov 2016 10:12:11 +0100
From: Christer Holmberg <>
To: Ivo Sedlacek <>, Randall Gellens <>, Az Mankin <>
Thread-Topic: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - ISSUE 7
Thread-Index: AQHSM47BSesWv686Q3CGsB9ygk2d86DDtQ/wgABPm4CAAEN1o4ABCFuAgACnkQCAAXnA1IAAU3gAgADM0IA=
Date: Fri, 4 Nov 2016 09:12:09 +0000
Message-ID: <>
References: <p06240600d43d18f64b41@> <> <p06240601d43e60ba377e@> <> <p06240601d4410f4338fa@[]> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7t+6bAJkIg/dXZS2WTt3JZNG46Cmr xffnXYwOzB47Z91l91iy5CeTx9Y7j1kCmKO4bFJSczLLUov07RK4Mp537mQs2KlUcWfPIZYG xg7pLkYODgkBE4nuPfZdjFwcQgLrGCW2/DnNDOEsZpRYsPg1O0gRm4CFRPc/7S5GTg4RgWqJ i7/nsYDYzAKqEucaH4PZwgIeEu2/z7JC1HhK3P05iQnCTpL4vm0dM8gYFgEVieuzg0HCvALW EmdmtzFCrLrOJPHnxQqwXk6BRImmGUvBbEYBMYnvp9YwQewSl7j1ZD6YLSEgILFkz3lmCFtU 4uXjf6wg80UF9CTW3A+DeEtJYtrWNIhOHYkFuz+xQdjWEtfb+xghbG2JZQtfM0OcIyhxcuYT lgmM4rOQLJuFpH0WkvZZSNpnIWlfwMi6ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMw+g5u +a26g/HyG8dDjAIcjEo8vB8CpCOEWBPLiitzDzFKcDArifDusZOJEOJNSaysSi3Kjy8qzUkt PsQozcGiJM5rtvJ+uJBAemJJanZqakFqEUyWiYNTqoHRvPnOrDlXVyy0Fj1vq8/xNsv9z9vm 9NDFL5Y3b9P6LHzZcp/QOY9TLUmb9Txf7/h3x/juaSWfUy/TteRUznn36z74Zh/QKC8bfGrh bNWWeRvf6y67sUbqwBGhL84nf0/X4jgy6dw5+RLfuWbcpZv2Cf9MmtbxlTnd7CzPppN6jALc XLPE03jklViKMxINtZiLihMBZFQdJLoCAAA=
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: Fri, 04 Nov 2016 09:12:16 -0000


If something is undefined, we should either define it, or use alternative

I suggested alternative terminology some time ago, but that was not
adopted either.



On 04/11/16 00:06, "Ecrit on behalf of Ivo Sedlacek"
< on behalf of> wrote:

>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
>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
>> >     the device is connected, and all service providers in the path of
>> >     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)
>> >     by reference.
>> >  -------------------
>> >  so I use "convey" when introducing rfc7852 in eCall draft.
>> RFC 7852 discusses equally sending data with the call and sending a
>> to data that is available externally, hence the use of the neutral term
>> "conveyance."  I think using "conveyance" in the eCall draft would be
>> well understood by the average reader than using "attach."  The term
>> seems pretty generally well understood, and the current language in the
>> 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
>> >     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
>Kind regards
>Ecrit mailing list