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

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Aug 2013 17:53:13 +0000

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)

---

From: Brian Rosen <[email-masked]>
Date: Tue, 6 Aug 2013 14:11:57 -0400

Not sure pictures in ascii art would help, but more words might.

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.

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:

> 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)
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Aug 2013 06:32:47 +0000

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

 

Regards,
 
Christer

---

From: James Winterbottom <[email-masked]>
Date: Wed, 7 Aug 2013 17:03:49 +1000

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]> wrote:

> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Brian Rosen <[email-masked]>
Date: Wed, 7 Aug 2013 08:52:29 -0400

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,
> >
> > 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.
> >>
> > 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
> >
> > [email-masked] <javascript:;>