Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding data

Hannes Tschofenig <hannes.tschofenig@gmx.net> Wed, 23 October 2013 11:58 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 2192011E8197 for <ecrit@ietfa.amsl.com>; Wed, 23 Oct 2013 04:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.622
X-Spam-Level:
X-Spam-Status: No, score=-102.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, 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 DjN5X8dYVD4Z for <ecrit@ietfa.amsl.com>; Wed, 23 Oct 2013 04:57:58 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 61DEA11E83C0 for <ecrit@ietf.org>; Wed, 23 Oct 2013 04:57:54 -0700 (PDT)
Received: from [172.16.254.200] ([80.92.115.161]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MexlN-1VNieX3TjN-00Obft for <ecrit@ietf.org>; Wed, 23 Oct 2013 13:57:53 +0200
Message-ID: <5267B9D9.2020102@gmx.net>
Date: Wed, 23 Oct 2013 13:58:17 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: James Winterbottom <a.james.winterbottom@gmail.com>, Brian Rosen <br@brianrosen.net>
References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <CAOPrzE37Lx-qxCCmRJ5RJX29t7EVyFZkESAEnAK5wCSySJDodw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> <ADE693DC-F327-4093-B06E-D89F1FFCA9DD@gmail.com> <CAOPrzE2nvpbPmfi0BmY-+wo6vZStQKvdEz5uFqt+8vX306biZA@mail.gmail.com> <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> <2949DC42-3D5B-4237-9F6A-BABE65A9E42A@brianrosen.net> <BC28EA87-48A1-4A4F-98AC-818C3EA7413C@gmail.com>
In-Reply-To: <BC28EA87-48A1-4A4F-98AC-818C3EA7413C@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:rTJ1/7isTpywihfTgEhDjJOVLvBPaZN1SkD3oAYjAM4+5nqMLEh iUidgAzZjo7ZfqeOcBdg3yJ9zozVk7xdoGTU1ZgDlFBnO+qstfN2vDrDkVqdkjFG0YYGqDm 8igJKDWKfnC1JHUkw/rPzDOqhVq9cVGeDSyF/3AV9r82//q/KbV3OKn5Wb9u+zkeYvikUx7 B08CvctkXHNA8DyF51MNw==
Cc: ecrit <ecrit@ietf.org>
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: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Wed, 23 Oct 2013 11:58:03 -0000

I just tried to create a longer example, as Christer requested, and the 
current structure indeed has some limitations (as discussed in this 
thread between James and Brian).

There are two approaches to solve the problem:

a) Introduce a hierarchical structure within the MIME bodies.

b) Link the data provider block with other blocks.

To me, it appears that option (b) is somewhat easier. All we have to do 
is the following:

1) Add a new element to the ProviderInfo block (let's call it <reference>)
2) Add a new element to the other blocks (let's call it <id>)
3) Add a requirement that all blocks added by a data provider must have 
the same value in <id>, which is then repeated in the <reference> element.

Of course, we have an id already in the MIME structure (in the form of a 
Content-ID). This would allow us to avoid defining the <id> in the 
structures but we would instead use the <reference> element to enumerate 
the content-ids. It does not exist in the XML. Is that a problem? For 
the provided-by structure, for example, we do not communite MIME 
structures but I suspect that the PIDF document would come from a single 
data provider anyway?!

Ciao
Hannes

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