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

[Hannes Tschofenig <[e-mail]>]

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
>