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

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 04 November 2016 09:12 UTC

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 335ED12963F for <ecrit@ietfa.amsl.com>; Fri, 4 Nov 2016 02:12:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn-1sJapXt0i for <ecrit@ietfa.amsl.com>; Fri, 4 Nov 2016 02:12:14 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C937129417 for <ecrit@ietf.org>; Fri, 4 Nov 2016 02:12:13 -0700 (PDT)
X-AuditID: c1b4fb25-953ff70000001e3e-f3-581c50ebea99
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id B6.AD.07742.BE05C185; Fri, 4 Nov 2016 10:12:12 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.177]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0319.002; Fri, 4 Nov 2016 10:12:11 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>, Randall Gellens <rg+ietf@randy.pensive.org>, Az Mankin <azmankin@gmail.com>
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: <D4421E5D.128D0%christer.holmberg@ericsson.com>
References: <p06240600d43d18f64b41@99.111.97.136> <181874aa-8dc1-8cd5-3ced-9965ba071b82@alum.mit.edu> <p06240601d43e60ba377e@99.111.97.136> <CAJD5LR2ueMF4DMWARUKBZu7M4w+_Amsc+Kd+TroSggHJN1CGsw@mail.gmail.com> <p06240601d4410f4338fa@[99.111.97.136]> <AM5PR0701MB2468715BF20ECE646B7E1095E5A30@AM5PR0701MB2468.eurprd07.prod.outlook.com>
In-Reply-To: <AM5PR0701MB2468715BF20ECE646B7E1095E5A30@AM5PR0701MB2468.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.9.160926
x-originating-ip: [153.88.183.147]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14B7A406EAD972449BFD8EBE0CA015D3@ericsson.com>
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: <https://mailarchive.ietf.org/arch/msg/ecrit/QlhtFbNwuJesgKKmA7x6wzp9f2c>
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - ISSUE 7
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Nov 2016 09:12:16 -0000

Hi,

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

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

Regards,

Christer




On 04/11/16 00:06, "Ecrit on behalf of Ivo Sedlacek"
<ecrit-bounces@ietf.org on behalf of ivo.sedlacek@ericsson.com> wrote:

>Randall,
>
>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
>
>Ivo
>
>_______________________________________________
>Ecrit mailing list
>Ecrit@ietf.org
>https://www.ietf.org/mailman/listinfo/ecrit