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

[Brian Rosen <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
>>>>>> <[e-mail] <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
>>>>>>> [e-mail] <javascript:;>
>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Ecrit mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>> 
>>