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

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 22 Oct 2013 17:54:48 +0200

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

---

From: Brian Rosen <[email-masked]>
Date: Tue, 22 Oct 2013 14:30:08 -0400

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 <[email-masked]> wrote:

> * Could we provide more and better examples? We have a number of examples in the document but we do not illustrate more complex versions.
> 
> * 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:
> 
> ------
> 
> 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:
> 
> ------
> 
> if these entities act as a source for additional data.  The data provider information block offers identification and contact information of the data source
>

---

From: James Winterbottom <[email-masked]>
Date: Wed, 23 Oct 2013 06:16:15 +1100

One way to do that is through schema structure and constraints.

Sent from my iPad

---

From: Brian Rosen <[email-masked]>
Date: Tue, 22 Oct 2013 15:21:18 -0400

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

---

From: James Winterbottom <[email-masked]>
Date: Wed, 23 Oct 2013 07:17:17 +1100

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

---

From: Brian Rosen <[email-masked]>
Date: Tue, 22 Oct 2013 16:51:31 -0400

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

---

From: James Winterbottom <[email-masked]>
Date: Wed, 23 Oct 2013 07:54:49 +1100

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

---

From: Brian Rosen <[email-masked]>
Date: Tue, 22 Oct 2013 17:07:44 -0400

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

---

From: James Winterbottom <[email-masked]>
Date: Wed, 23 Oct 2013 08:14:07 +1100

Yes, and so?
This is dead simple with schema and achieves the tie in a totally unambiguous way.

---

From: Brian Rosen <[email-masked]>
Date: Tue, 22 Oct 2013 17:20:56 -0400

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

---

From: James Winterbottom <[email-masked]>
Date: Wed, 23 Oct 2013 08:28:10 +1100

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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 Oct 2013 13:58:17 +0200

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

---

From: Brian Rosen <[email-masked]>
Date: Wed, 23 Oct 2013 09:03:22 -0400

I was thinking you would put <id> in all blocks (i.e. <reference>=<id>).  Every element, including the ProviderInfo block, gets the same id.

As I understand your proposal, every block except the ProviderId block would have nothing added, and the ProviderId blocks would have multiple entries, one per block beyond ProviderInfo that the provider included, containing the MIME content-id.  

While I think my original proposal is slightly better, because does not depend on knowing info in the MIME wrappers, it would be okay with me to use your idea

Brian.

On Oct 23, 2013, at 7:58 AM, Hannes Tschofenig <[email-masked]> 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).
> 
> To me, it appears that option (b) is somewhat easier. All we have to do is the following:
> 
> 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
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 Oct 2013 15:24:28 +0200

I am fine with your proposal. In any case, we definitely have to add the 
functionality.