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, 04 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
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Paul Kyzivat
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Randall Gellens
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Az Mankin
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Randall Gellens
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Christer Holmberg