Subject: [Ecrit] Extra "Type of Data Provider" token for additional-data

From: James Winterbottom <[email-masked]>
Date: Thu, 21 Jan 2016 18:49:09 +1100

Hi All,

In EENA we have been working on a Pan-European Mobile Emergency Application (architecture) PEMEA. This largely came about because mobile operators would not provide a US-style Phase II high-accuracy location implementation for mobile, and this refusal was because regulators, well, wouldn’t.

As a consequence, Europe, as in pretty much everywhere, except the US, associated territories and Canada, emergency application for smartphones have sprouted up everywhere. The problems is that they are very regional, and PEMEA seeks to address this through a meshed solution. Since the data is ancillary and doesn’t alleviate mobile operators of current responsibilities, it can operate as best effort. 

We are reusing the PIDF-LO, and the additional-data data structures, but we need a new type of data provider token, we need an “application provider” type.
I don’t really care what the token is called, but we are going to need it if we don’t want to use “other”, and given the way mobile communication application are sprouting up like weeds, in all seriousness we need this definition type , because conventional communication techniques will not meet the need of the current generation of citizens that communicate with almost any app except the traditional dial plans ones.

Cheers
James

---

From: Brian Rosen <[email-masked]>
Date: Thu, 21 Jan 2016 09:39:48 -0500

Makes sense.  How did you want to specify it?

Brian
> On Jan 21, 2016, at 2:49 AM, James Winterbottom <[email-masked]> wrote:
> 
> Hi All,
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: James Winterbottom <[email-masked]>
Date: Fri, 22 Jan 2016 06:31:32 +1100

“Application Provider”

That can then extend to other kinds of application provider if need be.

Cheers
James

> On 22 Jan 2016, at 1:39 am, Brian Rosen <[email-masked]> wrote:
>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 22 Jan 2016 08:56:47 -0500

Actually, I’m asking how you want to go about adding this value to the registry?  I think it might be too late to put it into the additional-data draft itself.  

Brian

> On Jan 21, 2016, at 2:31 PM, James Winterbottom <[email-masked]> wrote:
> 
> “Application Provider”
>

---

From: James Winterbottom <[email-masked]>
Date: Sun, 24 Jan 2016 17:12:06 +1100

I probably can’t until the registry is created then.

> On 23 Jan 2016, at 12:56 am, Brian Rosen <[email-masked]> wrote:
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 27 Jan 2016 18:46:07 +0100

Hi James,

I believe you should just add this entry to the registry once the
document is through the process. We intentionally added extension
capabilities and this is such an example.

Ciao
Hannes

---

From: Brian Rosen <[email-masked]>
Date: Wed, 27 Jan 2016 14:04:46 -0500

I noticed that we have a small wording problem in the document.  The TypeOfProvider that James wants to augment is in a registry defined in Section 11.1.5.  This value is a component of Data Provider Information and not Service Provider Information.  The name of the registry in the draft is “Service Provider Type” when it should be “Data Provider Type”.  In the first paragraph of 11.1.5, it refers to “ServiceProviderType” when the reference should be to “TypeOfProvider”.  The correct reference is used farther down the section text.  These could be handled in Auth48, although we should tell IANA about it.

The registry operates on Expert Review management, so as soon as the RFC is published and IANA creates the registry, EENA can ask for a new value.

Brian
> On Jan 27, 2016, at 12:46 PM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi James,
>

---

From: James Winterbottom <[email-masked]>
Date: Thu, 28 Jan 2016 10:14:43 +1100

I am worried a little about the race condition of which document gets published first. PEMEA will likely go out in the April timeframe.

Sent from my iPhone

> On 28 Jan 2016, at 6:01 am, Brian Rosen <[email-masked]> wrote:
> 
> I think this is a fine idea.  I agree that “other” is a bad idea.  You have a new kind of data provider, and we should have the proper token for it.
>