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

[Randall Gellens <[e-mail]>]

At 1:58 PM +0200 10/23/13, Hannes Tschofenig wrote:

>  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?!

This mechanism works fine for blocks provided by value.  I am not 
sure if blocks provided by reference will always have a Contend-ID 
when fetched, but perhaps it's irrelevant because the domain of the 
URL might serve the purpose.



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



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I'm prepared for all emergencies but totally unprepared for
everyday life.