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 12BB511E8282 for ; Tue, 22 Oct 2013 13:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.461 X-Spam-Level: X-Spam-Status: No, score=-103.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 EBiQ0ZEDaZPk for ; Tue, 22 Oct 2013 13:51:37 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7100911E8264 for ; Tue, 22 Oct 2013 13:51:37 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id 8so5183273qea.32 for ; Tue, 22 Oct 2013 13:51:34 -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=cFChMSsazUFwzONd32N8md4Hah5V+BV462cqTho03Cw=; b=jKVNudGnQWu4lMfe7j3msyUVahEd/3I3tNOW66rfYhuAGiDKFajzhjdkYagzj5D7wS U6J0zmOW0yvRIzi8997P9YGUcjXbILOKDKyGRo8NguAE4E7EOGS8QvjZzz1+r4MGdwt2 HKTJp0em/rQjrJGGMj7irKeSJtOBku2I+3rbREQemN7w1wTG0+qdhckZrhvMwGxV8g3B 5UFJ5wo31GcFyjbt2YZ45ERHCzTIXsx6RgDB5fa+t3sex8QJqPMfkJlxCJBxq8e792vR N81jGbFAqYkTYd6F0JKhohotn68YxzenMtARUddHlAstbebti9t4wThniblt2qSwTXwl Jx6A== X-Gm-Message-State: ALoCoQmj7sNaW3ZaLy/D/Sw7k+/71EO0lr2912er1Q+Fhq1Swmu7l5Bh96Fh6CeexvOeNO77qEZn X-Received: by 10.224.131.72 with SMTP id w8mr33427659qas.82.1382475094522; Tue, 22 Oct 2013 13:51:34 -0700 (PDT) Received: from [10.33.192.35] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id n7sm53653961qai.1.2013.10.22.13.51.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 13:51:33 -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: <0B5A3BCE-B92A-477B-9A7D-922F3B13265B@gmail.com> Date: Tue, 22 Oct 2013 16:51:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <58E93B5A-495E-4BB3-9231-944E04460C77@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> 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 20:51:42 -0000 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. 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. Brian On Oct 22, 2013, at 4:17 PM, James Winterbottom = wrote: > 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