Subject: Re: [Ecrit] Request for clarification: Dave Provider ID / Data Provider ID Series Usage (and Type of Data Provider)

From: Randall Gellens <[email-masked]>
Date: Thu, 2 Jul 2015 14:43:20 -0700

Hi Matt,

My apologies for not replying to this sooner, I intended to do so
when I made the other changes to -30.

The changes to -30 make it clear that the device fills in the
Data Provider block using 'device' as type of provider, and omits the
Provider ID and Provider ID Series.

At 10:41 PM +0000 5/26/15, Matt Serra wrote:

Content-Language: en-US

Content-Type: multipart/related;

boundary="_004_ed375d4434db4875baa41a892df4019dDAGN04AS1E7exg7exghostl_";

type="multipart/alternative"

I have not seen any comment on this, so
I'll try to bring the issue into sharper focus.

I'd appreciate knowing if there is
support for the Preferred Solution or Alternate Solution I outline
below (or if you have better idea).

Problem:

·         Within the Data
Provider Block, Data Provider ID and Provider ID Series are required
fields.

·         Per the DRAFT,
there are cases where an entity providing the Data Provider Block
would not be able to fill out these required fields as they are
defined, which in North America calls for populating a NENA Company ID
which an end-user would not have.

·         Examples of
entities that could not meet this requirement are end-user managed
devices or a user agent used to place an emergency call.

Preferred Solution:

·         Instruct the
Device or User Agent to populate Data Provider ID with the PAI or From
URI from the SIP INVITE

·         Instruct the
Device or User Agent to populate Data Provider ID Series with
'End-User' or a similar string.  Update the Provider ID
registry with this new value

·         Add a value to
the Type of Data Provider to read as "End User" "User Agent"
or similar

Alternate Solution:

·         Make the Data
Provider ID and Provider ID Series Conditional (optional where
provided by end-user device or user agent, otherwise
required)

·         Add a value to
the Type of Data Provider to read as "End User" "User Agent"
or similar to provide some context to the reader of the XML
document.

Thanks,

Matt.

From: Matt Serra

Sent: Monday, May 11, 2015 11:24 AM

To: [email-masked]

Subject: Request for clarification: Dave Provider ID / Data
Provider ID Series Usage (and Type of Data Provider)

Group:

In the Additional Call Data draft, the
Data Provider ID and Data Provider ID Series fields within the Data
Provider Information Block are shown as Required.

In addition to coming from a Service or
Access provider, the Additional Call Data can also be provided by the
device or user agent.

In the case of the Device or User Agent,
how should these blocks be populated?  The device or UA would not
have a NENA or EENA assigned Data Provider ID.  While the spec
allow for a "domain" to be used as a Provider ID, the domain alone
would not uniquely identify the device or User agent.  That
language seems to exist to accommodate Service and Access Network
providers.

So - it seems like we should EITHER
provide guidance on how to populate these fields in this case (perhaps
populate the Data Provider ID with From URI or PAI? And Data Provider
ID Series with "domain" or maybe "URI"?!?!)  OR make
these fields optional where provided by a device or user agent and
allow the From URI/PAI in the INVITE to speak for
themselves?

This also has ramifications on "Type of
Data Provider" as well.  There should be "Device" and
"User Agent" value(s) I'd think.

Thanks,

Matthew A. Serra, ENP

Sr. Director, Product Management

Mobile:  201.245.1557

[email-masked]

Content-Type: image/png; name="image001.png"

Content-Description: image001.png

Content-Disposition: inline; filename="image001.png";
size=3039;

creation-date="Tue, 26 May 2015
22:41:20 GMT";

modification-date="Tue, 26 May 2015
22:41:20 GMT"

Content-ID: <[email-masked]>

_______________________________________________

Ecrit mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/ecrit

--

Randall Gellens

Opinions are personal;    facts are
suspect;    I speak for myself only

-------------- Randomly selected tag: ---------------

One might say that the right's approach is to release the dogs of the

market, throwing all traditional values into disarray; and then, in

this tumult of insecurity, offer themselves up as the last bastion of

order and hierarchy, the stalwart defenders of the authority of

churches and fathers against the barbarians they have themselves

unleashed.  A scam it may be, but it is a remarkably effective one;

and one result is that the right ends up seeming to have a monopoly on

value.  --David Graeber, "Army of Altruists", Harper's, January 2007.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 2 Jul 2015 14:43:39 -0700

Hi Matt,

My apologies for not replying to this sooner, I 
intended to do so when I made the other changes 
to -30.

The changes to -30 make it clear that the device 
fills in the Data Provider block using 'device' 
as type of provider, and omits the Provider ID 
and Provider ID Series.

At 10:41 PM +0000 5/26/15, Matt Serra wrote:

>  I have not seen any comment on this, so I'll 
> try to bring the issue into sharper focus.
>
>  I'd appreciate knowing if there is support for 
> the Preferred Solution or Alternate Solution I 
> outline below (or if you have better idea).
>
>  Problem:
>  ·         Within the Data Provider Block, Data 
> Provider ID and Provider ID Series are required 
> fields.
>  ·         Per the DRAFT, there are cases where 
> an entity providing the Data Provider Block 
> would not be able to fill out these required 
> fields as they are defined, which in North 
> America calls for populating a NENA Company ID 
>  ·         Examples of entities that could not 
> meet this requirement are end-user managed 
>  ·         Instruct the Device or User Agent to 
> populate Data Provider ID with the PAI or From 
> URI from the SIP INVITE
>  ·         Instruct the Device or User Agent to 
> populate Data Provider ID Series with 
> 'End-User' or a similar string.  Update the 
> Provider ID registry with this new value
>  ·         Add a value to the Type of Data 
> Provider to read as "End User" "User Agent" or 
> similar
>
>  Alternate Solution:
>  ·         Make the Data Provider ID and 
> Provider ID Series Conditional (optional where 
> provided by end-user device or user agent, 
> otherwise required)
>  ·         Add a value to the Type of Data 
> Provider to read as "End User" "User Agent" or 
> similar to provide some context to the reader 
> of the XML document.
>
>  Thanks,
>
>  Matt.
>
>  From: Matt Serra
>  Subject: Request for clarification: Dave 
> Provider ID / Data Provider ID Series Usage 
> (and Type of Data Provider)
>
>  Group:
>
>  In the Additional Call Data draft, the Data 
> Provider ID and Data Provider ID Series fields 
> within the Data Provider Information Block are 
> shown as Required.
>
>  In addition to coming from a Service or Access 
> provider, the Additional Call Data can also be 
> provided by the device or user agent.
>
>  In the case of the Device or User Agent, how 
> should these blocks be populated?  The device 
> or UA would not have a NENA or EENA assigned 
> Data Provider ID.  While the spec allow for a 
> "domain" to be used as a Provider ID, the 
> domain alone would not uniquely identify the 
> device or User agent.  That language seems to 
> exist to accommodate Service and Access Network 
> providers.
>
>  So - it seems like we should EITHER provide 
> guidance on how to populate these fields in 
> this case (perhaps populate the Data Provider 
> ID with From URI or PAI? And Data Provider ID 
> Series with "domain" or maybe "URI"?!?!)  OR 
> make these fields optional where provided by a 
> device or user agent and allow the From URI/PAI 
> in the INVITE to speak for themselves?
>
>  This also has ramifications on "Type of Data 
> Provider" as well.  There should be "Device" 
> and "User Agent" value(s) I'd think.
>
>  Thanks,
>
>
>    Matthew A. Serra, ENP
>    <mailto:[email-masked]>[email-masked]
>
>
>
>  Content-Disposition: inline; filename="image001.png"; size=3039;
>  	creation-date="Tue, 26 May 2015 22:41:20 GMT";
>  	modification-date="Tue, 26 May 2015 22:41:20 GMT"

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Computers are useless.  They can only give you answers.
                            --Pablo Picasso (1881-1973)