Return-Path: 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 B5D7A11E8227 for ; Tue, 22 Oct 2013 14:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.478 X-Spam-Level: X-Spam-Status: No, score=-103.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, 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 GILrAX0-0vUI for ; Tue, 22 Oct 2013 14:21:00 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3B011E81C8 for ; Tue, 22 Oct 2013 14:21:00 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id cm18so35961qab.16 for ; Tue, 22 Oct 2013 14:20:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=TsoHywy3i/lz2vtcw933ddkw4nz5ZHRoJqnZAkK7qII=; b=loTfNh3d7sQffgyPIlZzZ+sk455dmktMX3wwF5lFKsK6qDjbhBZqc3GwP93Ipmt19J 11NDxfmcSfjIIp4ZSmZcPqiL5p1LDhVw61YAGapt3buY/zDAWVgmifANTyie0cD6RLNl jTfgJLDO6W5p6aDxN6nEY50PvMXbn8tc5uML+W0HeJ7kwwnbJzthsGzAQmcb5PMg90RG o5+kdP5FYkukL5jl9e107cKxoyNnQOpSwz6XwGQtEJDq5OIkyly/USoebDpjxX3dv9Rr YAsRxuS92EiOel50GX53SkckC4Yr49nm/dxXqPP+rH4R1KoRwKXu/D7ZI5U9nylN19Xp hw0A== X-Gm-Message-State: ALoCoQl21ZZCJrIRWUcAAL0NsEPOW9H2SO0RIEPQE/T+2SqQGfeJ0TY6qUZXz4+ZzZ5v3J68uNNZ X-Received: by 10.224.72.81 with SMTP id l17mr33025100qaj.54.1382476858865; Tue, 22 Oct 2013 14:20:58 -0700 (PDT) Received: from [10.33.192.35] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id 4sm53871087qak.11.2013.10.22.14.20.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 14:20:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Rosen In-Reply-To: <34694050-A1CE-492C-9F1C-00945C5E8FCD@gmail.com> Date: Tue, 22 Oct 2013 17:20:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2949DC42-3D5B-4237-9F6A-BABE65A9E42A@brianrosen.net> References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se>

<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> To: James Winterbottom X-Mailer: Apple Mail (2.1510) Cc: ecrit 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 21:21:04 -0000 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 = wrote: > Yes, and so? > This is dead simple with schema and achieves the tie in a totally = unambiguous way. >=20 > On 23/10/2013, at 8:07 AM, Brian Rosen wrote: >=20 >> Because the provider info is itself a block. Repeating it does = nothing. >>=20 >> We would have to make the content of the provider block a component = of every other block. >>=20 >> Brian >>=20 >> On Oct 22, 2013, at 4:54 PM, James Winterbottom = wrote: >>=20 >>> 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. >>>=20 >>> Cheers >>> James >>>=20 >>> On 23/10/2013, at 7:51 AM, Brian Rosen wrote: >>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> Brian >>>>=20 >>>> On Oct 22, 2013, at 4:17 PM, James Winterbottom = wrote: >>>>=20 >>>>> 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. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Sent from my iPad >>>>>=20 >>>>> On 23/10/2013, at 6:21 AM, Brian Rosen wrote: >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Oct 22, 2013, at 3:16 PM, James Winterbottom = wrote: >>>>>>=20 >>>>>>> One way to do that is through schema structure and constraints. >>>>>>>=20 >>>>>>>=20 >>>>>>> Sent from my iPad >>>>>>>=20 >>>>>>> On 23/10/2013, at 5:30 AM, Brian Rosen = wrote: >>>>>>>=20 >>>>>>>> I don't think this is sufficient. I think there has to be a = way to know which data provider which block. >>>>>>>>=20 >>>>>>>> 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 >>>>>>>>=20 >>>>>>>> Brian >>>>>>>>=20 >>>>>>>> On Oct 22, 2013, at 11:54 AM, Hannes Tschofenig = wrote: >>>>>>>>=20 >>>>>>>>> Hi Christer, Brian, James, >>>>>>>>>=20 >>>>>>>>> I believe you guys raised a couple of issues, namely: >>>>>>>>>=20 >>>>>>>>> * Could we provide more and better examples? We have a number = of examples in the document but we do not illustrate more complex = versions. >>>>>>>>>=20 >>>>>>>>> I am thinking about how to add a longer example. >>>>>>>>>=20 >>>>>>>>> * 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? >>>>>>>>>=20 >>>>>>>>> My suggestion is obvious: we have to double-check whether we = introduced a bug. >>>>>>>>>=20 >>>>>>>>> * 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: >>>>>>>>>=20 >>>>>>>>> ------ >>>>>>>>>=20 >>>>>>>>> 3.1. Data Provider Information >>>>>>>>>=20 >>>>>>>>> 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 >>>>>>>>>=20 >>>>>>>>> ------ >>>>>>>>>=20 >>>>>>>>> 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: >>>>>>>>>=20 >>>>>>>>> ------ >>>>>>>>>=20 >>>>>>>>> 3.1. Data Provider Information >>>>>>>>>=20 >>>>>>>>> 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 >>>>>>>>>=20 >>>>>>>>> The MIME subtype is = "application/emergencyCall.ProviderInfo+xml". >>>>>>>>>=20 >>>>>>>>> ------ >>>>>>>>>=20 >>>>>>>>> What do you think? >>>>>>>>>=20 >>>>>>>>> Ciao >>>>>>>>> Hannes >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> Brian >>>>>>>>>>=20 >>>>>>>>>> On Wednesday, August 7, 2013, James Winterbottom wrote: >>>>>>>>>>=20 >>>>>>>>>> Actually, I think that the requirement is more whether a = single >>>>>>>>>> entity should be able to add multiple types if information. >>>>>>>>>>=20 >>>>>>>>>> Cheers >>>>>>>>>> James >>>>>>>>>>=20 >>>>>>>>>> Sent from my iPhone >>>>>>>>>>=20 >>>>>>>>>> On 07/08/2013, at 4:32 PM, Christer Holmberg >>>>>>>>>> > wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hi Brian, >>>>>>>>>>>=20 >>>>>>>>>>>> Not sure pictures in ascii art would help, but more words = might. >>>>>>>>>>>=20 >>>>>>>>>>> I think some ascii art, showing the calling device (user or >>>>>>>>>> sensor), some intermediary ("server") and the PSAP would = help. >>>>>>>>>>>=20 >>>>>>>>>>>> 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. >>>>>>>>>>>>=20 >>>>>>>>>>>> With respect to multiple entities adding data, proxies = can't add >>>>>>>>>> bodies, but B2BUAs can. >>>>>>>>>>>=20 >>>>>>>>>>> Well, that is protocol/solution talk - the question is = whether >>>>>>>>>> there is a REQUIREMENT that multiple entities should be able = to add >>>>>>>>>> information :) >>>>>>>>>>>=20 >>>>>>>>>>> (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.) >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>>=20 >>>>>>>>>>> Christer >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Tuesday, August 6, 2013, Christer Holmberg wrote: >>>>>>>>>>> Hi, >>>>>>>>>>>=20 >>>>>>>>>>> The draft talks about all kind of different entities that = might >>>>>>>>>> add additional data to an emergency call. >>>>>>>>>>>=20 >>>>>>>>>>> First, I think it would be good to have some pictures = showing a >>>>>>>>>> few different scenarios. >>>>>>>>>>>=20 >>>>>>>>>>> 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? >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>>=20 >>>>>>>>>>> Christer >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Sent from Windows using TouchDown (www.nitrodesk.com >>>>>>>>>> ) >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Ecrit mailing list >>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> Ecrit mailing list >>>>>>>>>> Ecrit@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>=20 >>>>>>=20 >>>>=20 >>>=20 >>=20 >=20