Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 19 Feb 2013 19:31:01 +0000

I agree with Richard - there are countries where both the emergency service of the national police and the emergency service of the municipal police are offered in a given location.
A user would call the municipal police emergency service to report e.g. pickpockets.
A user would call the national police emergency service to report e.g. a murder.

I submitted to IANA a request to register:
- urn:service:sos.police.local - The 'police.local' service refers to the emergency service offered by the police department or other law enforcement authorities of the local or municipal authorities.
- urn:service:sos.police.national - The 'police.national' service refers to the emergency service offered by the police department or other law enforcement authorities of the national government.

RFC5031 policy is hopefully fulfilled for them since they exist in two countries.

I am flexible whether the actual URNs contain the sub-services proposed above (i.e. .local and .national sub-services) or subservices based on RFC4119 (i.e. .A3 and .country sub-services).

If the preference is for subservices based on RFC4119, do I need to make another IANA registration request or can we modify the URNs and their description during the expert review?

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>
From: Dan Mongrain [mailto:[email-masked]]
Sent: 19. února 2013 15:36
To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedlacek; [email-masked]
Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos

The problem is that different countries has different names for their political subdivisions.  In the US they are states, in Canada they are provinces, etc.  Same when you further subdivide.  While not privy to the discussions that came up with A1, A2, …, A5, I have the feeling this nomenclature was picked for the same reason.  Why not utilise the same naming scheme for specifying the jurisdiction you want to reach?

Thanx,
Dan

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <[email-masked]<mailto:[email-masked]>> wrote:
In that case, one might say state in the hierarchy, not A1.

Cheers
James

From: Richard Barnes [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, 19 February 2013 8:57 AM
To: Winterbottom, James
Cc: Dan Mongrain; Ivo Sedlacek; [email-masked]<mailto:[email-masked]>

Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos

It might make sense if you wanted to allow the caller to explicitly select police at a different level of responsibility, e.g., the state police rather than the local police.

On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James <[email-masked]<mailto:[email-masked]>> wrote:
I think I am missing something here, A1 is part of the location, so why does it need to be in the URN at all?
As far as I understand current deployments, they use the URN to select a layer in the GIS that corresponds to the service type, and then use geographic boundaries within that layer to select the final destination.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dan Mongrain
Sent: Tuesday, 19 February 2013 7:30 AM

To: Ivo Sedlacek
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos

Sorry for responding late to this thread, it kinda fell into a  crack…  The current thread reminded me to check this old thread…

You are indicating that we need to register 77 Service URN (11 service subtypes * 7 jurisdiction types based on RFC 4119).  I do not recommend that we create so many registrations.  Instead, we should allow a service URN to be suffixed with a jurisdictional scope.  So the following Service URN are all valid:

urn:service:sos.police
urn:service:sos.police.traffic
urn:service:sos.police.A1
urn:service:sos.police.traffic.A1

Question is, do we want to leave jurisdictional scope to only be applicable to police branch or any Service URN?  I’d say the latter as it is always up to the LoST service provisioning (based on local policy) to determine what is locally acceptable.

Thanx,
Dan

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 19 Feb 2013 14:35:27 -0500

The problem is the word "local".

What is "local" to you can be ambiguous in other areas.

This is the advantage of the proposal by Dan Mongrain - we can precisely specify the authority level.    If there is no specific agency at the level requested, the server can return the next highest level service that exists at the location in the query.

Brian

On Feb 19, 2013, at 2:31 PM, Ivo Sedlacek <[email-masked]<mailto:[email-masked]>> wrote:

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>
From: Dan Mongrain [mailto:[email-masked]<http://mongrain.org>]
Sent: 19. února 2013 15:36
To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedlacek; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos

Thanx,
Dan

Cheers
James

To: Ivo Sedlacek

urn:service:sos.police

Thanx,
Dan

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

---

From: Dan Mongrain <[email-masked]>
Date: Tue, 19 Feb 2013 15:12:18 -0500

Thing is, when there is no city police, local would give you county police
(sheriff department) but in a city with a city police department local
would give you city police.  In the latter case, so how do I get the county
police (or state police, there can be up to 4 police services for a given
location in the US).  Note that these examples are US based, but we do have
3 levels of police services in Canada and I am sure other countries have
the same issue.

There is also the terminology.  There is no "national" police in the US or
Canada but there is a federal police.  Keeping the RFC 4119 terminology
removes any "local" interpretation issues.

Dan

On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek <[email-masked]>wrote:

>  I agree with Richard - there are countries where both the emergency
> service of the national police and the emergency service of the municipal
> police are offered in a given location. ****
>
> A user would call the municipal police emergency service to report e.g.
> pickpockets.****
>
> A user would call the national police emergency service to report e.g. a
> murder.****
>
> ** **
>
> ** **
>
> I submitted to IANA a request to register:****
>
> - urn:service:sos.police.local - The 'police.local' service refers to the
> emergency service offered by the police department or other law enforcement
> authorities of the local or municipal authorities.****
>
> - urn:service:sos.police.national - The 'police.national' service refers
> to the emergency service offered by the police department or other law
> enforcement authorities of the national government.****
>
> ** **
>
> RFC5031 policy is hopefully fulfilled for them since they exist in two
> countries.****
>
> ** **
>
> I am flexible whether the actual URNs contain the sub-services proposed
> above (i.e. .local and .national sub-services) or subservices based on
> RFC4119 (i.e. .A3 and .country sub-services).****
>
> ** **
>
> If the preference is for subservices based on RFC4119, do I need to make
> another IANA registration request or can we modify the URNs and their
> description during the expert review?****
>
> ** **
>
> Kind regards****
>
> ** **
>
> Ivo Sedlacek****
>
> ** **
>
> This Communication is Confidential. We only send and receive email on the
> basis of the terms set out at www.ericsson.com/email_disclaimer ****
>
> *From:* Dan Mongrain [mailto:[email-masked]]
> *Sent:* 19. února 2013 15:36
> *To:* Winterbottom, James
> *Cc:* Richard Barnes; Ivo Sedlacek; [email-masked]
> *Subject:* Re: [Ecrit] What is the most appropriate method for
> registering new sub-services of urn:service:sos****
>
> ** **
>
> The problem is that different countries has different names for their
> political subdivisions.  In the US they are states, in Canada they are
> provinces, etc.  Same when you further subdivide.  While not privy to the
> discussions that came up with A1, A2, …, A5, I have the feeling this
> nomenclature was picked for the same reason.  Why not utilise the same
> naming scheme for specifying the jurisdiction you want to reach?****
>
>  ****
>
> Thanx,****
>
> Dan****
>
> ** **
>
> On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <
> [email-masked]> wrote:****
>
> In that case, one might say state in the hierarchy, not A1.****
>
>  ****
>
> Cheers****
>
> James****
>
>  ****
>
>  ****
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Sent:* Tuesday, 19 February 2013 8:57 AM
> *To:* Winterbottom, James
> *Cc:* Dan Mongrain; Ivo Sedlacek; [email-masked]****
>
>
> *Subject:* Re: [Ecrit] What is the most appropriate method for
> registering new sub-services of urn:service:sos****
>
>  ****
>
> It might make sense if you wanted to allow the caller to explicitly select
> police at a different level of responsibility, e.g., the state police
> rather than the local police.  ****
>
>  ****
>
> On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James <
> [email-masked]> wrote:****
>
> I think I am missing something here, A1 is part of the location, so why
> does it need to be in the URN at all?****
>
> As far as I understand current deployments, they use the URN to select a
> layer in the GIS that corresponds to the service type, and then use
> geographic boundaries within that layer to select the final destination.**
> **
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Dan Mongrain
> *Sent:* Tuesday, 19 February 2013 7:30 AM****
>
>
> *To:* Ivo Sedlacek
> *Cc:* [email-masked]
> *Subject:* Re: [Ecrit] What is the most appropriate method for
> registering new sub-services of urn:service:sos****
>
>  ****
>
> Sorry for responding late to this thread, it kinda fell into a  crack…
> The current thread reminded me to check this old thread…****
>
>  ****
>
> You are indicating that we need to register 77 Service URN (11 service
> subtypes * 7 jurisdiction types based on RFC 4119).  I do not recommend
> that we create so many registrations.  Instead, we should allow a service
> URN to be suffixed with a jurisdictional scope.  So the following Service
> URN are all valid:****
>
>  ****
>
> urn:service:sos.police****
>
> urn:service:sos.police.traffic****
>
> urn:service:sos.police.A1****
>
> urn:service:sos.police.traffic.A1****
>
>  ****
>
> Question is, do we want to leave jurisdictional scope to only be
> applicable to police branch or any Service URN?  I’d say the latter as it
> is always up to the LoST service provisioning (based on local policy) to
> determine what is locally acceptable.****
>
>  ****
>
> Thanx,****
>
> Dan****
>
> ** **
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 19 Feb 2013 20:31:35 +0000

Hello,

If we go with RFC4119 based sub-services, would the IANA registration request be as follows?

- urn:service:sos.police.A3 - The 'police.local' service refers to the emergency service offered by the police department or other law enforcement authorities of the authorities of a city, township, shi (JP).
- urn:service:sos.police.country - The 'police.national' service refers to the emergency service offered by the police department or other law enforcement authorities of the government of a country.

Does anyone see any issue in that?

If WG prefers this, it is OK for me.

> In the latter case, so how do I get the county police (or state police, there can be up to 4 police services for a given location in the US).

If I got it correctly, you propose that we also add
- urn:service:sos.police.A2 - The 'police.local' service refers to the emergency service offered by the police department or other law enforcement authorities of the authorities of county, parish, gun (JP), district (IN)"
- urn:service:sos.police.A1 - The 'police.local' service refers to the emergency service offered by the police department or other law enforcement authorities of the authorities of national subdivisions (state, region, province, prefecture)"

While I have no problem with that, I am not aware of a regulation establishing such emergency service so I cannot argue to IANA that the RFC5031 policy is satisfied for those URNs.

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>
From: Dan Mongrain [mailto:[email-masked]]
Sent: 19. února 2013 21:12
To: Ivo Sedlacek
Cc: Winterbottom, James; Richard Barnes; [email-masked]
Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

Thing is, when there is no city police, local would give you county police (sheriff department) but in a city with a city police department local would give you city police.  In the latter case, so how do I get the county police (or state police, there can be up to 4 police services for a given location in the US).  Note that these examples are US based, but we do have 3 levels of police services in Canada and I am sure other countries have the same issue.

There is also the terminology.  There is no "national" police in the US or Canada but there is a federal police.  Keeping the RFC 4119 terminology removes any "local" interpretation issues.

Dan
On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek <[email-masked]<mailto:[email-masked]>> wrote:
I agree with Richard - there are countries where both the emergency service of the national police and the emergency service of the municipal police are offered in a given location.
A user would call the municipal police emergency service to report e.g. pickpockets.
A user would call the national police emergency service to report e.g. a murder.

Kind regards

Ivo Sedlacek

From: Dan Mongrain [mailto:[email-masked]<mailto:[email-masked]>]

The problem is that different countries has different names for their political subdivisions.  In the US they are states, in Canada they are provinces, etc.  Same when you further subdivide.  While not privy to the discussions that came up with A1, A2, ..., A5, I have the feeling this nomenclature was picked for the same reason.  Why not utilise the same naming scheme for specifying the jurisdiction you want to reach?

Thanx,
Dan

Cheers
James

To: Ivo Sedlacek

Sorry for responding late to this thread, it kinda fell into a  crack...  The current thread reminded me to check this old thread...

urn:service:sos.police

Question is, do we want to leave jurisdictional scope to only be applicable to police branch or any Service URN?  I'd say the latter as it is always up to the LoST service provisioning (based on local policy) to determine what is locally acceptable.

Thanx,
Dan

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 20 Feb 2013 07:29:15 +0800

I am okay with this, providing that the fallback order is clearly defined.
That is, does an A3 fall back to an A2 or A1, or just back to sos?

From: Ivo Sedlacek [mailto:[email-masked]]
Sent: Wednesday, 20 February 2013 7:32 AM
To: Dan Mongrain
Cc: Winterbottom, James; Richard Barnes; [email-masked]
Subject: RE: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

Hello,

Kind regards

Ivo Sedlacek

Cc: Winterbottom, James; Richard Barnes; [email-masked]<mailto:[email-masked]>

Dan

Kind regards

Ivo Sedlacek

Thanx,
Dan

Cheers
James

To: Ivo Sedlacek

urn:service:sos.police

Thanx,
Dan

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 20 Feb 2013 01:18:06 +0100

The answer to James's question depends on how you code it (and also what you mean by fallback).

On any service URN, you ignore any subtypes from the point you stop understanding it.

So if the coding is sos.police.A2, and you do not understand A2, then the service URN would be handled as if it was sos.police, not as sos.police.A1. And if police was not understood then it would be handled as sos.

If you wanted something that went back to the next larger regional coverage, then you would have to code successive subtypes in sequence.

But I would also ask for an element of sanity in this discussion, rather than total flexibility.

For example while a national administration may have multiple levels of police force, not all of them are either reachable directly as an emergency service provider, nor are they necessarily an emergency service provider. If they are neither of these, then they presumably do not need a special and distinct service URN.

It would therefore nice to see a current use case that is anything but a choice of two, i.e. countrywide (following the ITU-T E.164 definition of country) versus one more local variant. This restricted model certainly covers Ivo's examples of Czeck Republic and Poland, and I believe it also covers the other example I know of which is Italy.

While the USA has multiple levels of police force, on the PSTN, it only appears to have one level of access to citizen to authority emergency service, which is 911. I see no reason why a change to voice over IP would cause a change to this.

I would also stress that it is important to have global expectations of what you get when you use a service URN. If there is not care excercised with assigning semantics and values, A3 in one country could result in the forestry police and in another country the financial police responding.

Note that read the scope of RFC 5031 as being for end user accessing the emergency service. While it might be possible to apply RFC 5031 to further network operations after the PSAP has been reached, e.g. to reach a subsidiary PSAP, I read that as outside the scope of RFC 5031. Nor do I necessarily believe in that scenario that service URNs are necessarily the best solution for routeing, as the first PSAP should know the particular office they want to reach rather than just the type of emergency service.

Regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Winterbottom, James
Sent: 19 February 2013 23:29
To: Ivo Sedlacek; Dan Mongrain
Cc: [email-masked]
Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

Hello,

Kind regards

Ivo Sedlacek

Dan

Kind regards

Ivo Sedlacek

Thanx,
Dan

Cheers
James

To: Ivo Sedlacek

urn:service:sos.police

Thanx,
Dan

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 20 Feb 2013 08:28:40 +0800

I tend agree with a lot of what you say here Keith .

My question was, as you say, is this police service hierarchical, so should it be defined as urn:service:sos.police.A1.A2.A3?

I think that the need for a citizen to make this determination is not needed, and if it is the triage PSAP making the determination then it is out of scope for RFC5031.

Cheers
James

From: DRAGE, Keith (Keith) [mailto:[email-masked]]
Sent: Wednesday, 20 February 2013 11:18 AM
To: Winterbottom, James; Ivo Sedlacek; Dan Mongrain
Cc: [email-masked]
Subject: RE: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

Regards

Keith

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Winterbottom, James

Hello,

Kind regards

Ivo Sedlacek

Dan

Kind regards

Ivo Sedlacek

Thanx,
Dan

Cheers
James

To: Ivo Sedlacek

urn:service:sos.police

Thanx,
Dan

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 20 Feb 2013 02:07:28 +0100

My understanding of at least the real life examples given so far is that the different police forces have different responsibilities. Therefore if the subtype is not understood one should go straight from sos.police.A2 to sos.police, rather than to A1.

Even if some country doesn't follow this and does have hierarchical responsibilities, then it is going to confuse roaming users, in either direction.

Note that in general all countries need to have a means of handling emergency calls without subtypes, so going straight up to sos.police will still be handled.

Keith

________________________________
From: Winterbottom, James [mailto:[email-masked]]
Sent: 20 February 2013 00:29
To: DRAGE, Keith (Keith); Ivo Sedlacek; Dan Mongrain
Cc: [email-masked]
Subject: RE: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

Cheers
James

Regards

Keith

Hello,

Kind regards

Ivo Sedlacek

Dan

Kind regards

Ivo Sedlacek

Thanx,
Dan

Cheers
James

To: Ivo Sedlacek

urn:service:sos.police

Thanx,
Dan

---

From: Dan Mongrain <[email-masked]>
Date: Tue, 19 Feb 2013 22:38:34 -0500

I would not refer to .country, .A1, .A2, ..., .A5 as RFC4119 based
sub-services but as Service URN jurisdictional qualifiers that can be
appended to any valid Service URN that specifies a scope to be used for the
search.  The jurisdictional qualifiers are used for:

.country for services at the country/national/federal/etc level
.A1 for services at the state/province/region/prefecture/etc level
.A2 for services at the county/parish/gun/district/etc level
.A3 for services at the city/township/shi/etc level
.A4 for services at the city division/borough/city district/ward/chou/etc
level
.A5 for services at the neighborhood/block/etc level

Thanx,
Dan

On Tue, Feb 19, 2013 at 3:31 PM, Ivo Sedlacek <[email-masked]>wrote:

>  Hello,****
>
> ** **
>
> If we go with RFC4119 based sub-services, would the IANA registration
> request be as follows?****
>
>  ****
>
> - urn:service:sos.police*.A3* - The 'police.local' service refers to the
> authorities of the authorities *of a city, township, shi (JP)*.****
>
> - urn:service:sos.police*.country* - The 'police.national' service refers
> enforcement authorities of the government *of a country*.****
>
> ** **
>
> Does anyone see any issue in that?****
>
> ** **
>
> If WG prefers this, it is OK for me.****
>
> ** **
>
> > In the latter case, so how do I get the county police (or state police,
> there can be up to 4 police services for a given location in the US).  ***
> *
>
> ** **
>
> If I got it correctly, you propose that we also add ****
>
> - urn:service:sos.police*.A2* - The 'police.local' service refers to the
> authorities of the authorities *of county, parish, gun (JP), district (IN)
> *"****
>
> - urn:service:sos.police*.A1* - The 'police.local' service refers to the
> authorities of the authorities *of national subdivisions (state, region,
> province, prefecture)*"****
>
> ** **
>
> While I have no problem with that, I am not aware of a regulation
> establishing such emergency service so I cannot argue to IANA that the
> RFC5031 policy is satisfied for those URNs.****
>
> ** **
>
> Kind regards****
>
> ** **
>
> Ivo Sedlacek****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *Sent:* 19. února 2013 21:12
> *To:* Ivo Sedlacek
> *Cc:* Winterbottom, James; Richard Barnes; [email-masked]
> registering new sub-services of urn:service:sos (trimming due too large
> message report)****
>
> ** **
>
> the same issue.****
> On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek <[email-masked]>
> wrote:****
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 20 Feb 2013 11:42:18 +0800

Hi Dan,

To be clear then, if you ask for urn:service:sos:police.A4 and it doesn't exist but A3 does, too bad you go straight to urn:service:sos:police ?

Cheers
James

From: Dan Mongrain [mailto:[email-masked]]
Sent: Wednesday, 20 February 2013 2:39 PM
To: Ivo Sedlacek
Cc: Winterbottom, James; Richard Barnes; [email-masked]
Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

I would not refer to .country, .A1, .A2, ..., .A5 as RFC4119 based sub-services but as Service URN jurisdictional qualifiers that can be appended to any valid Service URN that specifies a scope to be used for the search.  The jurisdictional qualifiers are used for:

.A4 for services at the city division/borough/city district/ward/chou/etc level

Thanx,
Dan
On Tue, Feb 19, 2013 at 3:31 PM, Ivo Sedlacek <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

Kind regards

Ivo Sedlacek

Dan

Kind regards

Ivo Sedlacek

Thanx,
Dan

Cheers
James

To: Ivo Sedlacek

urn:service:sos.police

Thanx,
Dan

---

From: Dan Mongrain <[email-masked]>
Date: Tue, 19 Feb 2013 23:22:49 -0500

My recommendation for handling unknown Service URN depends if LoST service
implements jurisdictional scope or not.  If it does not, it pops the last
element and evaluates until a service is found.  If it implements
jurisdictional scope, the last element is a jurisdictional scope and it is
not found, then you return the next highest level defined.

While it may be true that citizens typically dial 9-1-1 to request for
help, police services such as state or provincial polices advertises
numbers to call them directly (star code to dial using a mobile phone for
example) especially to report accidents on freeways.  We need an equivalent
Service URN.

Also while RFC5031's scope is citizen to authorities (I am not sure I agree
with this) I do not want to re-invent the wheel to signal calls within an
Emergency Services IP Network (ESInet).  When I transfer a call from one
PSAP to another, the mechanism to determine where to send the call is the
same, using LoST.  For a PSAP that covers a large area spanning multiple
counties and the calltaker needs to transfer the call to the appropriate
sheriff department for the caller's location, they only need a single
transfer target (urn:service:sos.police.A2).  It is not true that the
calltaker always knows the actual destination of the call, especially when
the calltaker is only a call screener.

Thanx,
Dan

On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

> ** ** ** ** ** ** **
>
> The answer to James’s question depends on how you code it (and also what
> you mean by fallback).****
>
> ** **
>
> On any service URN, you ignore any subtypes from the point you stop
> understanding it.****
>
> ** **
>
> So if the coding is sos.police.A2, and you do not understand A2, then the
> service URN would be handled as if it was sos.police, not as sos.police.A1.
> And if police was not understood then it would be handled as sos.****
>
> ** **
>
> If you wanted something that went back to the next larger regional
> coverage, then you would have to code successive subtypes in sequence.****
>
> ** **
>
> But I would also ask for an element of sanity in this discussion, rather
> than total flexibility.****
>
> ** **
>
> For example while a national administration may have multiple levels of
> police force, not all of them are either reachable directly as an emergency
> service provider, nor are they necessarily an emergency service provider.
> If they are neither of these, then they presumably do not need a special
> and distinct service URN. ****
>
> ** **
>
> It would therefore nice to see a current use case that is anything but a
> choice of two, i.e. countrywide (following the **ITU**-T E.164 definition
> of country) versus one more local variant. This restricted model certainly
> covers Ivo’s examples of **Czeck** **Republic** and **Poland**, and I
> believe it also covers the other example I know of which is ****Italy****.
> ****
>
> ** **
>
> While the ****USA**** has multiple levels of police force, on the PSTN,
> it only appears to have one level of access to citizen to authority
> emergency service, which is 911. I see no reason why a change to voice over
> IP would cause a change to this.****
>
> ** **
>
> I would also stress that it is important to have global expectations of
> what you get when you use a service URN. If there is not care excercised
> with assigning semantics and values, A3 in one country could result in the
> forestry police and in another country the financial police responding.***
> *
>
> ** **
>
> Note that read the scope of RFC 5031 as being for end user accessing the
> emergency service. While it might be possible to apply RFC 5031 to further
> network operations after the PSAP has been reached, e.g. to reach a
> subsidiary PSAP, I read that as outside the scope of RFC 5031. Nor do I
> necessarily believe in that scenario that service URNs are necessarily the
> best solution for routeing, as the first PSAP should know the particular
> office they want to reach rather than just the type of emergency service.*
> ***
>
> ** **
>
> Regards****
>
> ** **
>
> Keith****
>
> ** **
>   ------------------------------
>
> Of *Winterbottom, James
> *Sent:* 19 February 2013 23:29
> *To:* Ivo Sedlacek; Dan Mongrain
> *Cc:* [email-masked]
> That is, does an A3 fall back to an A2 or A1, or just back to sos?****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Ivo Sedlacek [mailto:[email-masked]]
> *Sent:* Wednesday, 20 February 2013 **7:32 AM**
> *To:* Dan Mongrain
> *Subject:* RE: [Ecrit] What is the most appropriate method for
> there can be up to 4 police services for a given location in the ****US***
> *).  ****
>
> ** **
>
> *From:* Dan Mongrain [mailto:[email-masked] <[email-masked]>]
> location in the ****US****).  Note that these examples are US based, but
> we do have 3 levels of police services in ****Canada**** and I am sure
> other countries have the same issue.****
>
>  ****
>
> There is also the terminology.  There is no "national" police in the **US*
> * or ****Canada**** but there is a federal police.  Keeping the RFC 4119
> terminology removes any "local" interpretation issues.
>
> Dan****
>
> On Tue, **Feb 19, 2013** at **2:31 PM**, Ivo Sedlacek <
> [email-masked]> wrote:****
>
> political subdivisions.  In the **US** they are states, in ****Canada****they are provinces, etc.  Same when you further subdivide.  While not privy
> to the discussions that came up with A1, A2, …, A5, I have the feeling this
> On Mon, **Feb 18, 2013** at **5:01 PM**, Winterbottom, James <
> *Sent:* Tuesday, 19 February 2013 **8:57 AM**
> On Mon, **Feb 18, 2013** at **4:21 PM**, Winterbottom, James <
> layer in the **GIS** that corresponds to the service type, and then use
> *Sent:* Tuesday, 19 February 2013 **7:30 AM******
>
>
> *To:* Ivo Sedlacek
> *Cc:* [email-masked]

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 20 Feb 2013 12:29:57 +0800

I am sorry, I am finding this confusing.

RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy to work then A1 through A6 can't be at the same level if you expect A3 to fallback to A2 or A1 in the case of a service not existing or a service failure of some kind. If they exist at the same level then if A3 doesn't exist you will go to urn:service:sos.police  unless you impose the hierarchy in the urn.

From: Dan Mongrain [mailto:[email-masked]]
Sent: Wednesday, 20 February 2013 3:23 PM
To: DRAGE, Keith (Keith)
Cc: Winterbottom, James; Ivo Sedlacek; [email-masked]
Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

My recommendation for handling unknown Service URN depends if LoST service implements jurisdictional scope or not.  If it does not, it pops the last element and evaluates until a service is found.  If it implements jurisdictional scope, the last element is a jurisdictional scope and it is not found, then you return the next highest level defined.

While it may be true that citizens typically dial 9-1-1 to request for help, police services such as state or provincial polices advertises numbers to call them directly (star code to dial using a mobile phone for example) especially to report accidents on freeways.  We need an equivalent Service URN.

Also while RFC5031's scope is citizen to authorities (I am not sure I agree with this) I do not want to re-invent the wheel to signal calls within an Emergency Services IP Network (ESInet).  When I transfer a call from one PSAP to another, the mechanism to determine where to send the call is the same, using LoST.  For a PSAP that covers a large area spanning multiple counties and the calltaker needs to transfer the call to the appropriate sheriff department for the caller's location, they only need a single transfer target (urn:service:sos.police.A2).  It is not true that the calltaker always knows the actual destination of the call, especially when the calltaker is only a call screener.

Thanx,
Dan
On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) <[email-masked]<mailto:[email-masked]>> wrote:
The answer to James's question depends on how you code it (and also what you mean by fallback).

Regards

Keith

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Winterbottom, James

From: Ivo Sedlacek [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, 20 February 2013 7:32 AM
To: Dan Mongrain
Cc: Winterbottom, James; Richard Barnes; [email-masked]<mailto:[email-masked]>
Subject: RE: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

Hello,

Kind regards

Ivo Sedlacek

Dan

Kind regards

Ivo Sedlacek

Thanx,
Dan

Cheers
James

To: Ivo Sedlacek

urn:service:sos.police

Thanx,
Dan

---

From: Dan Mongrain <[email-masked]>
Date: Tue, 19 Feb 2013 23:55:35 -0500

What I meant is that if a jurisdictional scope aware LoST service receives
a request for urn:service:sos.police.A4 and nothing is configured, it looks
for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until it
finds a configured service.  If nothing is found for
urn:service:sos.police.country then it pops the last element and looks for
urn:service:sos.police (but then again, it is no longer jurisdictional
scope aware).

I disagree that one needs to formulate the request as
urn:service:sos.police.country.A1.A2.A3.A4 in order for this to happen.
There must be only a single jurisdictional scope appended to a Service URN.

I do not think we need a .A6 jurisdictional scope (street level).  .A5
(neighborhood, would point to a precinct for example) provides enough
granularity in my opinion.

Thanx,
Dan

On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James <
[email-masked]> wrote:

> I am sorry, I am finding this confusing.****
>
> ** **
>
> RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy to
> work then A1 through A6 can’t be at the same level if you expect A3 to
> fallback to A2 or A1 in the case of a service not existing or a service
> failure of some kind. If they exist at the same level then if A3 doesn’t
> exist you will go to urn:service:sos.police  unless you impose the
> hierarchy in the urn.****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *Sent:* Wednesday, 20 February 2013 3:23 PM
> *To:* DRAGE, Keith (Keith)
> *Cc:* Winterbottom, James; Ivo Sedlacek; [email-masked]
> Also while RFC5031's scope is citizen to authorities (I am not sure I
> agree with this) I do not want to re-invent the wheel to signal calls
> within an Emergency Services IP Network (ESInet).  When I transfer a call
> from one PSAP to another, the mechanism to determine where to send the call
> is the same, using LoST.  For a PSAP that covers a large area spanning
> multiple counties and the calltaker needs to transfer the call to the
> appropriate sheriff department for the caller's location, they only need a
> single transfer target (urn:service:sos.police.A2).  It is not true that
> the calltaker always knows the actual destination of the call, especially
> when the calltaker is only a call screener.
>
> Thanx,
> Dan****
>
> [email-masked]> wrote:****
>
> choice of two, i.e. countrywide (following the ITU-T E.164 definition of
> country) versus one more local variant. This restricted model certainly
> covers Ivo’s examples of Czeck Republic and Poland, and I believe it also
> covers the other example I know of which is Italy.****
>
>  ****
>
> While the USA has multiple levels of police force, on the PSTN, it only
> appears to have one level of access to citizen to authority emergency
> service, which is 911. I see no reason why a change to voice over IP would
> cause a change to this.****
>
>  ****
>
> *Sent:* Wednesday, 20 February 2013 7:32 AM
> *To:* Dan Mongrain

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 20 Feb 2013 12:56:46 +0800

Thanks for the clarification, I personally disagree with that position.

From: Dan Mongrain [mailto:[email-masked]]
Sent: Wednesday, 20 February 2013 3:56 PM
To: Winterbottom, James
Cc: DRAGE, Keith (Keith); Ivo Sedlacek; [email-masked]
Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

What I meant is that if a jurisdictional scope aware LoST service receives a request for urn:service:sos.police.A4 and nothing is configured, it looks for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until it finds a configured service.  If nothing is found for urn:service:sos.police.country then it pops the last element and looks for urn:service:sos.police (but then again, it is no longer jurisdictional scope aware).

I disagree that one needs to formulate the request as urn:service:sos.police.country.A1.A2.A3.A4 in order for this to happen.  There must be only a single jurisdictional scope appended to a Service URN.

I do not think we need a .A6 jurisdictional scope (street level).  .A5 (neighborhood, would point to a precinct for example) provides enough granularity in my opinion.

Thanx,
Dan

On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James <[email-masked]<mailto:[email-masked]>> wrote:
I am sorry, I am finding this confusing.

From: Dan Mongrain [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, 20 February 2013 3:23 PM
To: DRAGE, Keith (Keith)
Cc: Winterbottom, James; Ivo Sedlacek; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

Thanx,
Dan

Regards

Keith

Hello,

Kind regards

Ivo Sedlacek

Dan

Kind regards

Ivo Sedlacek

Thanx,
Dan

Cheers
James

To: Ivo Sedlacek

urn:service:sos.police

Thanx,
Dan

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 20 Feb 2013 09:03:17 +0100

You seem to be assuming that a call to the police is automatically an emergency call.

My understanding is that most police forces advertise these local numbers specifically for cases where it is NOT an emergency call. As a quick reference to Wikipedia (incomplete but readily available) shows only one number for Canada.

I would like you to describe your case for signalling calls within an Esinet and I do not believe these cases were considered when RFC 5031 was developed nor are they written into the scope of that document That is not described in any RFC, and if we are extending to that capability, it would help to know which decision points are made using service URNs, and consider whether that is better than other solutions.

For the accidents on freeway, see my summary posting made recently. You will see that other countries, e.g. China  have these as an entirely separate emergency service, and in my belief that should probably not be sos.police.... but sos.trafficemergency.

Keith

Sent: 20 February 2013 04:23

Thanx,
Dan

Regards

Keith

Hello,

Kind regards

Ivo Sedlacek

Dan

Kind regards

Ivo Sedlacek

Thanx,
Dan

Cheers
James

To: Ivo Sedlacek

urn:service:sos.police

Thanx,
Dan

---

From: Marc Linsner <[email-masked]>
Date: Wed, 20 Feb 2013 08:48:05 -0500

The findService request includes location information.  Why wouldn't the
LoST server simple walk the A1-A6 tree included with the location?  If
location is geo, reverse geocode it.

What am I missing?

-Marc-

From:  Dan Mongrain <[email-masked]>
Date:  Tuesday, February 19, 2013 11:55 PM
To:  "Winterbottom, James" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [Ecrit] What is the most appropriate method for registering
new sub-services of urn:service:sos (trimming due too large message report)

> What I meant is that if a jurisdictional scope aware LoST service receives a
> request for urn:service:sos.police.A4 and nothing is configured, it looks for
> urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until it finds
> a configured service.  If nothing is found for urn:service:sos.police.country
> then it pops the last element and looks for urn:service:sos.police (but then
> again, it is no longer jurisdictional scope aware).
> 
> urn:service:sos.police.country.A1.A2.A3.A4 in order for this to happen.  There
> must be only a single jurisdictional scope appended to a Service URN.
> 
> On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James
> <[email-masked]> wrote:
>> RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy to work
>> then A1 through A6 can¹t be at the same level if you expect A3 to fallback to
>> A2 or A1 in the case of a service not existing or a service failure of some
>> kind. If they exist at the same level then if A3 doesn¹t exist you will go to
>> urn:service:sos.police  unless you impose the hierarchy in the urn.
>>  
>>  
>>  
>>  
>>  
>> 
>> Subject: Re: [Ecrit] What is the most appropriate method for registering new
>> sub-services of urn:service:sos (trimming due too large message report)
>>  
>> While it may be true that citizens typically dial 9-1-1 to request for help,
>> police services such as state or provincial polices advertises numbers to
>> call them directly (star code to dial using a mobile phone for example)
>> especially to report accidents on freeways.  We need an equivalent Service
>> URN.
>> 
>> Emergency Services IP Network (ESInet).  When I transfer a call from one PSAP
>> to another, the mechanism to determine where to send the call is the same,
>> using LoST.  For a PSAP that covers a large area spanning multiple counties
>> and the calltaker needs to transfer the call to the appropriate sheriff
>> department for the caller's location, they only need a single transfer target
>> (urn:service:sos.police.A2).  It is not true that the calltaker always knows
>> the actual destination of the call, especially when the calltaker is only a
>> call screener.
>> 
>> Thanx,
>> Dan
>> 
>> On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith)
>> <[email-masked]> wrote:
>> 
>> The answer to James¹s question depends on how you code it (and also what you
>> mean by fallback).
>>  
>> understanding it.
>> And if police was not understood then it would be handled as sos.
>>  
>> If you wanted something that went back to the next larger regional coverage,
>> then you would have to code successive subtypes in sequence.
>>  
>> service provider, nor are they necessarily an emergency service provider. If
>> they are neither of these, then they presumably do not need a special and
>> distinct service URN.
>>  
>> covers Ivo¹s examples of Czeck Republic and Poland, and I believe it also
>> covers the other example I know of which is Italy.
>>  
>> cause a change to this.
>> I would also stress that it is important to have global expectations of what
>> you get when you use a service URN. If there is not care excercised with
>> assigning semantics and values, A3 in one country could result in the
>> forestry police and in another country the financial police responding.
>>  
>> office they want to reach rather than just the type of emergency service.
>>  
>> Regards
>>  
>> Keith
>>  
>> 
>> 
>> Subject: Re: [Ecrit] What is the most appropriate method for registering new
>> sub-services of urn:service:sos (trimming due too large message report)
>>  
>> Subject: RE: [Ecrit] What is the most appropriate method for registering new
>> sub-services of urn:service:sos (trimming due too large message report)
>>  
>> Hello,
>>  
>> - urn:service:sos.police.A3 - The 'police.local' service refers to the
>> authorities of the authorities of a city, township, shi (JP).
>> - urn:service:sos.police.country - The 'police.national' service refers to
>> the emergency service offered by the police department or other law
>> enforcement authorities of the government of a country.
>>  
>>> there can be up to 4 police services for a given location in the US).
>>  
>> - urn:service:sos.police.A2 - The 'police.local' service refers to the
>> authorities of the authorities of county, parish, gun (JP), district (IN)"
>> - urn:service:sos.police.A1 - The 'police.local' service refers to the
>> authorities of the authorities of national subdivisions (state, region,
>> province, prefecture)"
>>  
>> RFC5031 policy is satisfied for those URNs.
>>  
>> Kind regards
>>  
>> Ivo Sedlacek
>>  
>>  
>>  
>>  
>> basis of the terms set out at www.ericsson.com/email_disclaimer
>> <http://www.ericsson.com/email_disclaimer>
>> Subject: Re: [Ecrit] What is the most appropriate method for registering new
>> sub-services of urn:service:sos (trimming due too large message report)
>>  
>> (sheriff department) but in a city with a city police department local would
>> give you city police.  In the latter case, so how do I get the county police
>> (or state police, there can be up to 4 police services for a given location
>> in the US).  Note that these examples are US based, but we do have 3 levels
>> of police services in Canada and I am sure other countries have the same
>> issue.
>>  
>> wrote:
>> I agree with Richard - there are countries where both the emergency service
>> of the national police and the emergency service of the municipal police are
>> offered in a given location.
>> pickpockets.
>> murder.
>> authorities of the local or municipal authorities.
>> - urn:service:sos.police.national - The 'police.national' service refers to
>> the emergency service offered by the police department or other law
>> enforcement authorities of the national government.
>>  
>> countries.
>> I am flexible whether the actual URNs contain the sub-services proposed above
>> (i.e. .local and .national sub-services) or subservices based on RFC4119
>> (i.e. .A3 and .country sub-services).
>>  
>> description during the expert review?
>>  
>> Kind regards
>>  
>> Ivo Sedlacek
>>  
>> basis of the terms set out at www.ericsson.com/email_disclaimer
>> <http://www.ericsson.com/email_disclaimer>
>> discussions that came up with A1, A2, Š, A5, I have the feeling this
>> nomenclature was picked for the same reason.  Why not utilise the same naming
>> scheme for specifying the jurisdiction you want to reach?
>>  
>> Thanx,
>> Dan
>>  
>> 
>> On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James
>> <[email-masked]> wrote:
>> 
>> From: Richard Barnes [mailto:[email-masked]]
>> Cc: Dan Mongrain; Ivo Sedlacek; [email-masked]
>> 
>> 
>> police at a different level of responsibility, e.g., the state police rather
>> than the local police.
>> 
>>  
>> 
>> On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James
>> <[email-masked]> wrote:
>> 
>> geographic boundaries within that layer to select the final destination.
>>  
>> 
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
>> Mongrain
>> Sorry for responding late to this thread, it kinda fell into a  crackŠ  The
>> current thread reminded me to check this old threadŠ
>>  
>> subtypes * 7 jurisdiction types based on RFC 4119).  I do not recommend that
>> we create so many registrations.  Instead, we should allow a service URN to
>> be suffixed with a jurisdictional scope.  So the following Service URN are
>> all valid:
>>  
>> urn:service:sos.police
>> Question is, do we want to leave jurisdictional scope to only be applicable
>> to police branch or any Service URN?  I¹d say the latter as it is always up
>> to the LoST service provisioning (based on local policy) to determine what is
>> locally acceptable.
>>  
>> Thanx,
>> Dan
>>  
>>  
>>  
> 
> _______________________________________________ Ecrit mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/ecrit

---

From: Dan Mongrain <[email-masked]>
Date: Wed, 20 Feb 2013 12:13:08 -0500

Some provincial and state police can be called directly in an emergency.
This is extracted from their web sites:

Kentucky: "If you have an emergency situation, please use the Kentucky
State Police Hotline phone
numbers<http://www.kentuckystatepolice.org/contact.htm#emerge>to reach
us."
Virginia: "For emergencies, call 9-1-1 or your local law enforcement agency
or Virginia State Police office." "Dial #77 on a cellular telephone. Dial
#77 on a cellular telephone.  This is the most effective means to report a
reckless and dangerous driver to the Virginia State Police."
New Jersey: "For emergencies call 911 or your local police, sheriff, or
State Police Office."
Tennessee: "Contact Us Statewide via Mobile Phone: *THP (*847) for Highway
Emergencies to connect to the THP District Headquarters nearest you at the
time of your call."
Ohio: "Contact the Patrol by Phone: #677" This is to report reckless or
drunk driving."
Florida: "Star FHP (*347) is a cellular phone program used by motorists to
report drunk drivers, traffic crashes, stranded or disabled motorists, or
any suspicious incidents occurring on Florida roadways."*
*
Georgia: "To report impaired drivers and highway emergencies - Dial *GSP on
your cell phone or dial 911."
Kansas: "Need help? Use your cellular phone to call *47 or *KTA"
Québec: "URGENCE Composez immédiatement le: *4141 (pour les cellulaires) 24
heures sur 24, 7 jours sur 7"

The Kansas State Highway Patrol website at "
http://www.kansashighwaypatrol.org/about/state_contact.html" displays the
emergency contact numbers for all 50 US states.  A majority of the states
have a number where to reach the state police directly.

So there is already a well established practice of calling another number
other than 9-1-1 (for US and Canada) for reporting emergencies to the
state/provincial authorities.

Also, in some states (California and Massachusetts come to mind) all mobile
emergency calls are sent to state police (this is from the original
assumption that mobile 9-1-1 calls were to report traffic emergencies).
This basically means that for the same location, there are two different
PSAPs depending on the source of the call.

I think the demonstration is made that we need a Service URN to be able to
specify the desired jurisdiction for a given location.  My proposal for
using RFC 4119 nomenclature allows for this and gets around the whole issue
of local terminology (city vs. municipal, state vs. province, national vs.
federal, etc.).

The problem with using urn:service:sos.police.traffic" is that there are
two agencies that provide assistance for traffic emergencies depending on
where it occurs.  On state/provincial highways and freeways you can call
the state/provincial police where elsewhere you call the city or county
police.

As for signalling on the ESInet, in the E9-1-1 system there is already the
concept of "Selective Transfers" where the primary PSAP that answers the
9-1-1 call transfers the call to the appropriate secondary PSAP based on
the caller's location.  The calltaker uses star codes (such as *11 for
police, *12 for fire, *13 for medical, *14 for sheriff, *15 for state
police, etc.) and the Selective Router selects the appropriate secondary
PSAP based on the caller's location (the territory is divided into
Emergency Services Zones and each zone has translation tables for
specifying where each star code points to).  A calltaker does not need to
specify the exact agency to direct an emergency call to and also can cover
a much larger geographic area where there is a multitude of secondary
agencies.  In NG9-1-1, the star codes are replaced with Service URNs which
will specify not only the service subtype ".police, .fire, .medical, etc.)
but also the jurisdiction in the case there are multiple agencies that
provide the same service subtype (such as .police).  By looking at the
source of the request, a LoST service can either ignore service subtypes
(as in the case of a call from a citizen that requests .fire or .medical)
or respect the service subtype (when requests comes from a PSAP).

The provisioning of the LoST service is always based on local policies.
For states that do not allow emergency calls to be routed directly to the
state police, findService requests for urn:service:sos.police.A2 can return
the URI for urn:service:sos.

Thanx,
Dan
**
    *
*
On Wed, Feb 20, 2013 at 3:03 AM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

> ** ** ** ** ** ** **
>
> You seem to be assuming that a call to the police is automatically an
> emergency call.****
>
> ** **
>
> My understanding is that most police forces advertise these local numbers
> specifically for cases where it is NOT an emergency call. As a quick
> reference to Wikipedia (incomplete but readily available) shows only one
> number for ****Canada****.****
>
> ** **
>
> I would like you to describe your case for signalling calls within an
> Esinet and I do not believe these cases were considered when RFC 5031 was
> developed nor are they written into the scope of that document That is not
> described in any RFC, and if we are extending to that capability, it would
> help to know which decision points are made using service URNs, and
> consider whether that is better than other solutions.****
>
> ** **
>
> For the accidents on freeway, see my summary posting made recently. You
> will see that other countries, e.g. ****China****  have these as an
> entirely separate emergency service, and in my belief that should probably
> not be sos.police…. but sos.trafficemergency.****
>
> ** **
>
> Keith****
>
> ** **
> *Sent:* 20 February 2013 04:23
> On Tue, **Feb 19, 2013** at **7:18 PM**, DRAGE, Keith (Keith) <

---

From: Dan Mongrain <[email-masked]>
Date: Wed, 20 Feb 2013 12:30:02 -0500

I do not understand your comment.  What I am proposing is that requests do
not specify a search pattern in the case a requested jurisdiction is not
found.  It should not be to the requester which submits
urn:service:sos.police.country.A1.A2.A3.A4
to specify what to do if there is nothing configured for the A4 layer.  It
must be up to the LoST service to apply whatever policy it has in this
case.  If we allow this, then do we allow urn:service:sos.police.fire?
Give me fire first but if not found give me police?

The Service URN should specify the "desired" service in a findService
request and the LoST service provides a response based on local policies.
All I am proposing is that one can specify a jurisdiction in the case there
are more then one service provider for a location.

Thanx,
Dan

On Wed, Feb 20, 2013 at 8:48 AM, Marc Linsner <[email-masked]> wrote:

>> My recommendation for handling unknown Service URN depends if LoST
>> service implements jurisdictional scope or not.  If it does not, it pops
>> the last element and evaluates until a service is found.  If it implements
>> forestry police and in another country the financial police responding.**
>> **
>>
>>  ****
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Winterbottom, James
>> - urn:service:sos.police*.country* - The 'police.national' service
>> refers to the emergency service offered by the police department or other
>> law enforcement authorities of the government *of a country*.****
>>
>>  ****
>>
>> > In the latter case, so how do I get the county police (or state
>> police, there can be up to 4 police services for a given location in the
>> US).  ****
>>
>>  ****
>>
>> authorities of the authorities *of county, parish, gun (JP), district
>> (IN)*"****
>>
>> Thing is, when there is no city police, local would give you county
>> police (sheriff department) but in a city with a city police department
>> local would give you city police.  In the latter case, so how do I get the
>> county police (or state police, there can be up to 4 police services for a
>> given location in the US).  Note that these examples are US based, but we
>> do have 3 levels of police services in Canada and I am sure other countries
>> have the same issue.****
>>
>>  ****
>>
>> There is also the terminology.  There is no "national" police in the US
>> or Canada but there is a federal police.  Keeping the RFC 4119 terminology
>> It might make sense if you wanted to allow the caller to explicitly
>> select police at a different level of responsibility, e.g., the state
>> police rather than the local police.  ****
>>
>>  ****
>>
>> geographic boundaries within that layer to select the final destination.*
>> ***
>>
>>  ****
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Dan Mongrain

---

From: Marc Linsner <[email-masked]>
Date: Wed, 20 Feb 2013 14:47:58 -0500

I understood you as requesting urn:service:sos.police.A4.

My point was that if the LoST service had no entry for A4, it could simply
check the Ax tree submitted in the location section of the request.  So if
the location included A1 & A4, the LoST service, finding nothing for A4
would then check A1 (not A3 or A2).  This way the service would be matching
the hierarchy of the given location vs. an arbitrary hierarchy that may be
different from the requestors desire.

Carry onŠ

-Marc-

From:  Dan Mongrain <[email-masked]>
Date:  Wednesday, February 20, 2013 12:30 PM
To:  Marc Linsner <[email-masked]>
Cc:  "Winterbottom, James" <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject:  Re: [Ecrit] What is the most appropriate method for registering
new sub-services of urn:service:sos (trimming due too large message report)

> I do not understand your comment.  What I am proposing is that requests do not
> specify a search pattern in the case a requested jurisdiction is not found.
> It should not be to the requester which submits
> urn:service:sos.police.country.A1.A2.A3.A4 to specify what to do if there is
> nothing configured for the A4 layer.  It must be up to the LoST service to
> apply whatever policy it has in this case.  If we allow this, then do we allow
> urn:service:sos.police.fire?  Give me fire first but if not found give me
> police?
> 
> The Service URN should specify the "desired" service in a findService request
> and the LoST service provides a response based on local policies.  All I am
> proposing is that one can specify a jurisdiction in the case there are more
> then one service provider for a location.
> 
> Thanx,
> Dan
> 
>> The findService request includes location information.  Why wouldn't the LoST
>> server simple walk the A1-A6 tree included with the location?  If location is
>> geo, reverse geocode it.
>> 
>> What am I missing?
>> 
>> -Marc-
>> 
>>> request for urn:service:sos.police.A4 and nothing is configured, it looks
>>> urn:service:sos.police (but then again, it is no longer jurisdictional scope
>>> aware).
>>> 
>>>> work then A1 through A6 can¹t be at the same level if you expect A3 to
>>>> failure of some kind. If they exist at the same level then if A3 doesn¹t
>>>> hierarchy in the urn.
>>>> The answer to James¹s question depends on how you code it (and also what
>>>> you mean by fallback).
>>>>  
>>>> coverage, then you would have to code successive subtypes in sequence.
>>>>  
>>>> than total flexibility.
>>>> and distinct service URN.
>>>>  
>>>> Subject: RE: [Ecrit] What is the most appropriate method for registering
>>>> request be as follows?
>>>> of the national police and the emergency service of the municipal police
>>>> are offered in a given location.
>>>> RFC4119 (i.e. .A3 and .country sub-services).
>>>>  
>>>> new sub-services of urn:service:sos
>>>>  
>>>> naming scheme for specifying the jurisdiction you want to reach?
>>>>  
>>>> Thanx,
>>>> Dan
>>>>  
>>>> 
>>>> new sub-services of urn:service:sos
>>>> 
>>>>  
>>>> 
>>>> rather than the local police.
>>>> 
>>>>  
>>>> 
>>>> does it need to be in the URN at all?
>>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>>> Dan Mongrain
>>>> new sub-services of urn:service:sos
>>>> 
>>>>  
>>>> URN are all valid:
>>>> to the LoST service provisioning (based on local policy) to determine what
>>>> is locally acceptable.
>>>>  
>>>> Thanx,
>>>> Dan
>>>>  
>>>>  
>>>>  
>>> 
>>> [email-masked]://www.ietf.org/mailman/listinfo/ecrit
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 20 Feb 2013 14:56:00 -0500

To me, this doesn't make sense.

Suppose I have a local police department in cities, but a provincial police department in rural areas, as well as a national police.  I ask for sos.police.A3.  If location was in a city, I should get sos.police.A3

But if I was in a rural area, a request for sos.police.A3 should return a response of sos.police.A2.

That may or may not be the same as sos.police

Brian

On Feb 20, 2013, at 2:47 PM, Marc Linsner <[email-masked]<mailto:[email-masked]>> wrote:

My point was that if the LoST service had no entry for A4, it could simply check the Ax tree submitted in the location section of the request.  So if the location included A1 & A4, the LoST service, finding nothing for A4 would then check A1 (not A3 or A2).  This way the service would be matching the hierarchy of the given location vs. an arbitrary hierarchy that may be different from the requestors desire.

Carry on…

-Marc-

From: Dan Mongrain <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 20, 2013 12:30 PM
To: Marc Linsner <[email-masked]<mailto:[email-masked]>>
Cc: "Winterbottom, James" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

I do not understand your comment.  What I am proposing is that requests do not specify a search pattern in the case a requested jurisdiction is not found.  It should not be to the requester which submits urn:service:sos.police.country.A1.A2.A3.A4 to specify what to do if there is nothing configured for the A4 layer.  It must be up to the LoST service to apply whatever policy it has in this case.  If we allow this, then do we allow urn:service:sos.police.fire?  Give me fire first but if not found give me police?

The Service URN should specify the "desired" service in a findService request and the LoST service provides a response based on local policies.  All I am proposing is that one can specify a jurisdiction in the case there are more then one service provider for a location.

Thanx,
Dan

On Wed, Feb 20, 2013 at 8:48 AM, Marc Linsner <[email-masked]<mailto:[email-masked]>> wrote:
The findService request includes location information.  Why wouldn't the LoST server simple walk the A1-A6 tree included with the location?  If location is geo, reverse geocode it.

What am I missing?

-Marc-

From: Dan Mongrain <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 19, 2013 11:55 PM
To: "Winterbottom, James" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

Thanx,
Dan

RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy to work then A1 through A6 can’t be at the same level if you expect A3 to fallback to A2 or A1 in the case of a service not existing or a service failure of some kind. If they exist at the same level then if A3 doesn’t exist you will go to urn:service:sos.police  unless you impose the hierarchy in the urn.

Thanx,
Dan
On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) <[email-masked]<mailto:[email-masked]>> wrote:
The answer to James’s question depends on how you code it (and also what you mean by fallback).

It would therefore nice to see a current use case that is anything but a choice of two, i.e. countrywide (following the ITU-T E.164 definition of country) versus one more local variant. This restricted model certainly covers Ivo’s examples of Czeck Republic and Poland, and I believe it also covers the other example I know of which is Italy.

Regards

Keith

Hello,

Kind regards

Ivo Sedlacek

Dan

Kind regards

Ivo Sedlacek

Thanx,
Dan

Cheers
James

To: Ivo Sedlacek

urn:service:sos.police

Thanx,
Dan

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

---

From: Marc Linsner <[email-masked]>
Date: Wed, 20 Feb 2013 15:16:24 -0500

What if I don't want A2 (I don't trust Butler County sheriff), if no A3
(Mars) give me A1 (PA)?

What I proposed allows the requestor to tailor the request to match his
desire.

The fallback is multiple requests.

-Marc-

From:  "Rosen, Brian" <[email-masked]>
Date:  Wednesday, February 20, 2013 2:56 PM
To:  Marc Linsner <[email-masked]>
Cc:  Dan Mongrain <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  Re: [Ecrit] What is the most appropriate method for registering
new sub-services of urn:service:sos (trimming due too large message report)

> Suppose I have a local police department in cities, but a provincial police
> department in rural areas, as well as a national police.  I ask for
> sos.police.A3.  If location was in a city, I should get sos.police.A3
> 
> On Feb 20, 2013, at 2:47 PM, Marc Linsner <[email-masked]> wrote:
> 
>> the location included A1 & A4, the LoST service, finding nothing for A4 would
>> then check A1 (not A3 or A2).  This way the service would be matching the
>> hierarchy of the given location vs. an arbitrary hierarchy that may be
>>> apply whatever policy it has in this case.  If we allow this, then do we
>>> allow urn:service:sos.police.fire?  Give me fire first but if not found give
>>> me police?
>>> 
>>>>> a request for urn:service:sos.police.A4 and nothing is configured, it
>>>>> looks for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc.
>>>>> until it finds a configured service.  If nothing is found for
>>>>>> the last element and evaluates until a service is found.  If it
>>>>>> implements jurisdictional scope, the last element is a jurisdictional
>>>>>> scope and it is not found, then you return the next highest level
>>>>>> defined.
>>>>>> 
>>>>>> example) especially to report accidents on freeways.  We need an
>>>>>> equivalent Service URN.
>>>>>> 
>>>>>> from one PSAP to another, the mechanism to determine where to send the
>>>>>> call is the same, using LoST.  For a PSAP that covers a large area
>>>>>> spanning multiple counties and the calltaker needs to transfer the call
>>>>>> to the appropriate sheriff department for the caller's location, they
>>>>>> only need a single transfer target (urn:service:sos.police.A2).  It is
>>>>>> not true that the calltaker always knows the actual destination of the
>>>>>> call, especially when the calltaker is only a call screener.
>>>>>> 
>>>>>> Thanx,
>>>>>> Dan
>>>>>> 
>>>>>> service URN would be handled as if it was sos.police, not as
>>>>>> sos.police.A1. And if police was not understood then it would be handled
>>>>>> as sos.
>>>>>>  
>>>>>> police force, not all of them are either reachable directly as an
>>>>>> emergency service provider, nor are they necessarily an emergency service
>>>>>> provider. If they are neither of these, then they presumably do not need
>>>>>> a special and distinct service URN.
>>>>>>  
>>>>>> service, which is 911. I see no reason why a change to voice over IP
>>>>>> would cause a change to this.
>>>>>>  
>>>>>> with assigning semantics and values, A3 in one country could result in
>>>>>> the forestry police and in another country the financial police
>>>>>> responding.
>>>>>>  
>>>>>> emergency service. While it might be possible to apply RFC 5031 to
>>>>>> further network operations after the PSAP has been reached, e.g. to reach
>>>>>> a subsidiary PSAP, I read that as outside the scope of RFC 5031. Nor do I
>>>>>> necessarily believe in that scenario that service URNs are necessarily
>>>>>> the best solution for routeing, as the first PSAP should know the
>>>>>> particular office they want to reach rather than just the type of
>>>>>> emergency service.
>>>>>>  
>>>>>> Regards
>>>>>>  
>>>>>> Keith
>>>>>>  
>>>>>> 
>>>>>> Winterbottom, James
>>>>>> emergency service offered by the police department or other law
>>>>>> enforcement authorities of the authorities of a city, township, shi (JP).
>>>>>> - urn:service:sos.police.country - The 'police.national' service refers
>>>>>>> US).  
>>>>>> emergency service offered by the police department or other law
>>>>>> enforcement authorities of the authorities of county, parish, gun (JP),
>>>>>> district (IN)"
>>>>>> emergency service offered by the police department or other law
>>>>>> enforcement authorities of the authorities of national subdivisions
>>>>>> (state, region, province, prefecture)"
>>>>>>  
>>>>>> local would give you city police.  In the latter case, so how do I get
>>>>>> the county police (or state police, there can be up to 4 police services
>>>>>> for a given location in the US).  Note that these examples are US based,
>>>>>> but we do have 3 levels of police services in Canada and I am sure other
>>>>>> countries have the same issue.
>>>>>>  
>>>>>> or Canada but there is a federal police.  Keeping the RFC 4119
>>>>>> police are offered in a given location.
>>>>>> emergency service offered by the police department or other law
>>>>>> enforcement authorities of the local or municipal authorities.
>>>>>> police rather than the local police.
>>>>>>  
>>>>>> 
>>>>>> Sorry for responding late to this thread, it kinda fell into a  crackŠ
>>>>>> The current thread reminded me to check this old threadŠ
>>>>>>  
>>>>>> applicable to police branch or any Service URN?  I¹d say the latter as it
>>>>>> determine what is locally acceptable.
>>>>>>  
>>>>>> Thanx,
>>>>>> Dan
>>>>>>  
>>>>>>  
>>>>>>  
>>>>> 
>> [email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 20 Feb 2013 15:19:46 -0500

If you don't want A2, repeat the request with A1.  You know that you got A2, so you know when you have to do that.  It's a corner case at best.

Brian

On Feb 20, 2013, at 3:16 PM, Marc Linsner <[email-masked]<mailto:[email-masked]>> wrote:

What if I don't want A2 (I don't trust Butler County sheriff), if no A3 (Mars) give me A1 (PA)?

What I proposed allows the requestor to tailor the request to match his desire.

-Marc-

From: "Rosen, Brian" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 20, 2013 2:56 PM
To: Marc Linsner <[email-masked]<mailto:[email-masked]>>
Cc: Dan Mongrain <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

Brian

Carry on…

-Marc-

Thanx,
Dan

What am I missing?

-Marc-

Thanx,
Dan

Thanx,
Dan

Regards

Keith

Hello,

Kind regards

Ivo Sedlacek

Dan

Kind regards

Ivo Sedlacek

Thanx,
Dan

Cheers
James

To: Ivo Sedlacek

urn:service:sos.police

Thanx,
Dan

---

From: Dan Mongrain <[email-masked]>
Date: Wed, 20 Feb 2013 15:22:17 -0500

The typical civic address includes A6, A3 and A1.  A2 is not always
populated as it can be inferred from A3 and A1.  But if one requests
urn:service:sos.police.A3
but there is no such agency then it is perfectly valid to return the A2
level service (even if A2 was not populated in the provided location).  The
LoST service knows this information.  This can be the default behaviour
when dealing with a jurisdictional scope that is not found, return the next
configured level up. But as always, local provisioning prevails which could
provide a lower service instead.

Dan

On Wed, Feb 20, 2013 at 2:47 PM, Marc Linsner <[email-masked]> wrote:

> Cc: "Winterbottom, James" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> found.  It should not be to the requester which submits urn:service:sos.police.country.A1.A2.A3.A4
>> What I meant is that if a jurisdictional scope aware LoST service
>> receives a request for urn:service:sos.police.A4 and nothing is configured,
>> it looks for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc.
>>> So if the coding is sos.police.A2, and you do not understand A2, then
>>> the service URN would be handled as if it was sos.police, not as
>>> sos.police.A1. And if police was not understood then it would be handled as
>>> sos.****
>>>
>>>  ****
>>>
>>> forestry police and in another country the financial police responding.*
>>> ***
>>>
>>>  ****
>>>
>>> I am okay with this, providing that the fallback order is clearly
>>> defined.****
>>>
>>> - urn:service:sos.police*.A3* - The 'police.local' service refers to
>>> enforcement authorities of the authorities *of a city, township, shi
>>> (JP)*.****
>>>
>>> - urn:service:sos.police*.A2* - The 'police.local' service refers to
>>> enforcement authorities of the authorities *of county, parish, gun
>>> (JP), district (IN)*"****
>>>
>>> - urn:service:sos.police*.A1* - The 'police.local' service refers to
>>> enforcement authorities of the authorities *of national subdivisions
>>> (state, region, province, prefecture)*"****
>>>
>>>  ****
>>>
>>> This Communication is Confidential. We only send and receive email on
>>> the basis of the terms set out at www.ericsson.com/email_disclaimer ****
>>>
>>> - urn:service:sos.police.local - The 'police.local' service refers to
>>> enforcement authorities of the local or municipal authorities.****
>>>
>>> This Communication is Confidential. We only send and receive email on
>>> the basis of the terms set out at www.ericsson.com/email_disclaimer ****
>>>

---

From: Dan Mongrain <[email-masked]>
Date: Wed, 20 Feb 2013 15:32:55 -0500

We should not infer anything from missing information especially if this
information is optional (as my previous message shows).  Doing anything
else is misleading at best.  Requester makes a request specifying desired
service nothing more.  You may ask for sos.fire, but you are getting sos as
you cannot call .fire directly, local policy.  If you do not like the
answer, try again if you want with a different service (same service
request will give same response back).

Dan

On Wed, Feb 20, 2013 at 3:16 PM, Marc Linsner <[email-masked]> wrote:

> Suppose I have a local police department in cities, but a provincial
> police department in rural areas, as well as a national police.  I ask for

---

From: Marc Linsner <[email-masked]>
Date: Wed, 20 Feb 2013 16:15:07 -0500

Not sure I agree with your summation.  In your example, .sos IS the proper
way to call .fire.  Just because .sos is also the proper way to call .police
is irrelevant.

Maybe it would be best to use a DNS-like approach.  No record = 'not found'.
No ambiguity this way.  Populate .sos and .sos.fire and .sos.police all with
the same uri if that is the response you want.  If request is for .sos.help
and the jurisdiction doesn't support .help, the response is 'not found'.
Why try to guess what was requested?

-Marc-

From:  Dan Mongrain <[email-masked]>
Date:  Wednesday, February 20, 2013 3:32 PM
To:  Marc Linsner <[email-masked]>
Cc:  "Rosen, Brian" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject:  Re: [Ecrit] What is the most appropriate method for registering
new sub-services of urn:service:sos (trimming due too large message report)

> information is optional (as my previous message shows).  Doing anything else
> is misleading at best.  Requester makes a request specifying desired service
> nothing more.  You may ask for sos.fire, but you are getting sos as you cannot
> call .fire directly, local policy.  If you do not like the answer, try again
> if you want with a different service (same service request will give same
> response back).
> 
> Dan
> 
>>>>> urn:service:sos.police.country.A1.A2.A3.A4 to specify what to do if there
>>>>> is nothing configured for the A4 layer.  It must be up to the LoST service
>>>>> to apply whatever policy it has in this case.  If we allow this, then do
>>>>> we allow urn:service:sos.police.fire?  Give me fire first but if not found
>>>>> give me police?
>>>>> 
>>>>> All I am proposing is that one can specify a jurisdiction in the case
>>>>> there are more then one service provider for a location.
>>>>> 
>>>>> Thanx,
>>>>> Dan
>>>>> 
>>>>>>> receives a request for urn:service:sos.police.A4 and nothing is
>>>>>>> configured, it looks for urn:service:sos.police.A3 then
>>>>>>> urn:service:sos.police.A2, etc. until it finds a configured service.  If
>>>>>>> nothing is found for urn:service:sos.police.country then it pops the
>>>>>>> last element and looks for urn:service:sos.police (but then again, it is
>>>>>>> no longer jurisdictional scope aware).
>>>>>>> 
>>>>>>> numbers to call them directly (star code to dial using a mobile phone
>>>>>>> for example) especially to report accidents on freeways.  We need an
>>>>>>> equivalent Service URN.
>>>>>>> 
>>>>>>> within an Emergency Services IP Network (ESInet).  When I transfer a
>>>>>>> call from one PSAP to another, the mechanism to determine where to send
>>>>>>> the call is the same, using LoST.  For a PSAP that covers a large area
>>>>>>> emergency service provider, nor are they necessarily an emergency
>>>>>>> service provider. If they are neither of these, then they presumably do
>>>>>>> not need a special and distinct service URN.
>>>>>>>  
>>>>>>> covers Ivo¹s examples of Czeck Republic and Poland, and I believe it
>>>>>>> also covers the other example I know of which is Italy.
>>>>>>>  
>>>>>>> further network operations after the PSAP has been reached, e.g. to
>>>>>>> reach a subsidiary PSAP, I read that as outside the scope of RFC 5031.
>>>>>>> Nor do I necessarily believe in that scenario that service URNs are
>>>>>>> necessarily the best solution for routeing, as the first PSAP should
>>>>>>> know the particular office they want to reach rather than just the type
>>>>>>> of emergency service.
>>>>>>>  
>>>>>>> Regards
>>>>>>>  
>>>>>>> Keith
>>>>>>>  
>>>>>>> 
>>>>>>>> police, there can be up to 4 police services for a given location in
>>>>>>>> the US).  
>>>>>>>  
>>>>>>> the basis of the terms set out at www.ericsson.com/email_disclaimer
>>>>>>> On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek
>>>>>>> <[email-masked]> wrote:
>>>>>>> service of the national police and the emergency service of the
>>>>>>> municipal police are offered in a given location.
>>>>>>> the basis of the terms set out at www.ericsson.com/email_disclaimer
>>>>>>> provinces, etc.  Same when you further subdivide.  While not privy to
>>>>>>> the discussions that came up with A1, A2, Š, A5, I have the feeling this
>>>>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>>>> Of Dan Mongrain
>>>>>>> that we create so many registrations.  Instead, we should allow a
>>>>>>> service URN to be suffixed with a jurisdictional scope.  So the
>>>>>>> following Service URN are all valid:
>>>>>>>  
>>>>>>> urn:service:sos.police
>>>>>>> applicable to police branch or any Service URN?  I¹d say the latter as
>>>>>>> it is always up to the LoST service provisioning (based on local policy)
>>>>>>> to determine what is locally acceptable.
>>>>>>>  
>>>>>>> Thanx,
>>>>>>> Dan
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>>

---

From: Nathan Wilcox <[email-masked]>
Date: Wed, 20 Feb 2013 16:02:55 -0600

+1

On Feb 20, 2013, at 3:15 PM, Marc Linsner <[email-masked]> wrote:

> Not sure I agree with your summation.  In your example, .sos IS the proper way to call .fire.  Just because .sos is also the proper way to call .police is irrelevant.
> 
> Maybe it would be best to use a DNS-like approach.  No record = 'not found'.  No ambiguity this way.  Populate .sos and .sos.fire and .sos.police all with the same uri if that is the response you want.  If request is for .sos.help and the jurisdiction doesn't support .help, the response is 'not found'.  Why try to guess what was requested?
> 
> -Marc-
> 
> 
> 
> Cc: "Rosen, Brian" <[email-masked]>, "[email-masked]" <[email-masked]>
>> We should not infer anything from missing information especially if this information is optional (as my previous message shows).  Doing anything else is misleading at best.  Requester makes a request specifying desired service nothing more.  You may ask for sos.fire, but you are getting sos as you cannot call .fire directly, local policy.  If you do not like the answer, try again if you want with a different service (same service request will give same response back).
>> 
>> Dan
>> 
>>>>> Cc: "Winterbottom, James" <[email-masked]>, "[email-masked]" <[email-masked]>
>>>>>>>> On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James <[email-masked]> wrote:
>>>>>>>>> On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) <[email-masked]> wrote:
>>>>>>>>> This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer
>>>>>>>>> On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek <[email-masked]> wrote:
>>>>>>>>> This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer
>>>>>>>>> On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <[email-masked]> wrote:
>>>>>>>>> On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James <[email-masked]> wrote:
>>>>>>>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Mongrain
>>>>>>>> _______________________________________________ Ecrit mailing list [email-masked]://www.ietf.org/mailman/listinfo/ecrit
>>>>>>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 20 Feb 2013 18:25:10 -0500

Yes.  This.

My first reaction to these suggestions of chaining was "It's a provisioning
problem -- just put the same contact information under all those URNs."

On Wed, Feb 20, 2013 at 5:02 PM, Nathan Wilcox <[email-masked]> wrote:

> way to call .fire.  Just because .sos is also the proper way to call
> .police is irrelevant.
>
> Maybe it would be best to use a DNS-like approach.  No record = 'not
> found'.  No ambiguity this way.  Populate .sos and .sos.fire and
> .sos.police all with the same uri if that is the response you want.  If
> request is for .sos.help and the jurisdiction doesn't support .help, the
> response is 'not found'.  Why try to guess what was requested?
>
> -Marc-
>
>
>
>> My point was that if the LoST service had no entry for A4, it could
>> simply check the Ax tree submitted in the location section of the request.
>>  So if the location included A1 & A4, the LoST service, finding nothing for
>> A4 would then check A1 (not A3 or A2).  This way the service would be
>> matching the hierarchy of the given location vs. an arbitrary hierarchy
>> that may be different from the requestors desire.
>>
>> Carry on…
>>
>> -Marc-
>>
>> I do not understand your comment.  What I am proposing is that requests
>> do not specify a search pattern in the case a requested jurisdiction is not
>>> Subject: Re: [Ecrit] What is the most appropriate method for
>>> message report)
>>>> RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy
>>>> to work then A1 through A6 can’t be at the same level if you expect A3 to
>>>> The answer to James’s question depends on how you code it (and also
>>>> what you mean by fallback).****
>>>>  ****
>>>> But I would also ask for an element of sanity in this discussion,
>>>> rather than total flexibility.****
>>>>  ****
>>>> It would therefore nice to see a current use case that is anything but
>>>> a choice of two, i.e. countrywide (following the ITU-T E.164 definition of
>>>> Note that read the scope of RFC 5031 as being for end user accessing
>>>> the emergency service. While it might be possible to apply RFC 5031 to
>>>> further network operations after the PSAP has been reached, e.g. to reach a
>>>> On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek <
>>>> A user would call the national police emergency service to report e.g.
>>>> a murder.****
>>>>  ****
>>>>  ****
>>>> - urn:service:sos.police.national - The 'police.national' service
>>>> law enforcement authorities of the national government.****
>>>>  ****
>>>> If the preference is for subservices based on RFC4119, do I need to
>>>> make another IANA registration request or can we modify the URNs and their
>>>> As far as I understand current deployments, they use the URN to select
>>>> a layer in the GIS that corresponds to the service type, and then use

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 21 Feb 2013 09:44:39 -0500

I'm okay with that also.

Let's make sure we understand what we are talking about - I was having a private conversation with someone which lead me to believe we may not all understand.

This situation ONLY occurs in countries that don't have a single number, or a single number for a given type of service (police for example).

This situation ONLY occurs when there is non-uniform coverage.  The easy example is that there are local police in large cities, but provincial police cover rural areas, and there are separate dial strings for local and provincial police.

We're discussing what happens, effectively, when you dial the local number.
* In some countries, you get e.g. the provincial police (that is, it automatically redirects)
* In some countries, you get a fast busy or other intercept (that is, you don't get connected and have to redial)

Now, we're really in a different environment.  I do worry about what we are asking phones to do.
LoST returns dial strings.  We need to get, in this case, the local and provincial dial strings.

urn:service:sos.police should return no service
urn:service:sos.police.A1 should return the provincial police dial string and provincial police URL
urn:service:sos.police.A2 should return no service
urn:service:sos.police.A3 should return the local dial string.  The URL could be that of the local police, the provincial police, or it could be some URL that results in a fast busy or other intercept.

Brian

On Feb 20, 2013, at 6:25 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:

Yes.  This.

My first reaction to these suggestions of chaining was "It's a provisioning problem -- just put the same contact information under all those URNs."

On Wed, Feb 20, 2013 at 5:02 PM, Nathan Wilcox <[email-masked]<mailto:[email-masked]>> wrote:
+1

On Feb 20, 2013, at 3:15 PM, Marc Linsner <[email-masked]<mailto:[email-masked]>> wrote:

-Marc-

Cc: "Rosen, Brian" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Dan

On Wed, Feb 20, 2013 at 3:16 PM, Marc Linsner <[email-masked]<mailto:[email-masked]>> wrote:
What if I don't want A2 (I don't trust Butler County sheriff), if no A3 (Mars) give me A1 (PA)?

-Marc-

Brian

Carry on…

-Marc-

Thanx,
Dan

What am I missing?

-Marc-

Thanx,
Dan

Thanx,
Dan

Regards

Keith

Hello,

Kind regards

Ivo Sedlacek

Dan

Kind regards

Ivo Sedlacek

Thanx,
Dan

Cheers
James

To: Ivo Sedlacek

urn:service:sos.police

Thanx,
Dan

---

From: Dan Mongrain <[email-masked]>
Date: Thu, 21 Feb 2013 10:29:19 -0500

While it is a provisioning issue, we are dealing with emergency calls
here.  We are talking about introducing a number of subServices that may
not be available in all areas.  While a client SHOULD not request this
subService in areas where it is not offered as it SHOULD have listed the
services available when entering the area, the LoST service must be able to
deal with the case the client still requests an unknown subService.  It
could return a Not Found and let the client deal with it (the client SHOULD
be intelligent enough to handle properly and not propagate error to user).
Also the LoST service SHOULD be provisioned in such a way that if it gets
an unknown subService it is handled. Still a lot of SHOULDs for an
emergency call to succeed.

We could mandate that a LoST server must give a default handling in the
case the Service URN is in the sos tree.  The most sensible way to handle
an unknown subService is to unroll the Service URN (i.e. pop the last
element in the Service URN) and re-evaluate.  Most LoST service will be
provisioned for urn:service:sos (the equivalent to dialing 9-1-1 or 1-1-2)
so any subService down the sos tree will be handled.  While I suggested
that when you get a request with an unknown jurisdictional scope you should
look for the next higher jurisdiction, the more I think about it, it should
be treated the same as an unknown subService.  Just unroll the Service URN
(pop the jurisdictional scope) and re-evaluate.

Dan

On Wed, Feb 20, 2013 at 6:25 PM, Richard Barnes <[email-masked]> wrote:

> Yes.  This.
>
> My first reaction to these suggestions of chaining was "It's a
> provisioning problem -- just put the same contact information under all
> those URNs."
>
>
>> Not sure I agree with your summation.  In your example, .sos IS the
>> proper way to call .fire.  Just because .sos is also the proper way to call
>> .police is irrelevant.
>>
>>> On Wed, Feb 20, 2013 at 8:48 AM, Marc Linsner <[email-masked]>wrote:
>>>
>>>> The findService request includes location information.  Why wouldn't
>>>> the LoST server simple walk the A1-A6 tree included with the location?  If
>>>>> For example while a national administration may have multiple levels
>>>>> of police force, not all of them are either reachable directly as an
>>>>> provider. If they are neither of these, then they presumably do not need a
>>>>> special and distinct service URN. ****
>>>>>  ****
>>>>> While the USA has multiple levels of police force, on the PSTN, it
>>>>> only appears to have one level of access to citizen to authority emergency
>>>>> I would also stress that it is important to have global expectations
>>>>> of what you get when you use a service URN. If there is not care excercised
>>>>> There is also the terminology.  There is no "national" police in the
>>>>> US or Canada but there is a federal police.  Keeping the RFC 4119
>>>>> A user would call the municipal police emergency service to report
>>>>> e.g. pickpockets.****
>>>>> I am flexible whether the actual URNs contain the sub-services
>>>>> proposed above (i.e. .local and .national sub-services) or subservices
>>>>> based on RFC4119 (i.e. .A3 and .country sub-services).****
>>>>>  ****
>>>>> I think I am missing something here, A1 is part of the location, so
>>>>> why does it need to be in the URN at all?****
>>>>> Sorry for responding late to this thread, it kinda fell into a
>>>>> crack…  The current thread reminded me to check this old thread…****
>>>>>  ****

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 22 Feb 2013 07:18:47 +0800

Wouldn't the LoST server simply include the response with a warning if the mapping was substituted?
This then let's URN pruning occur and the UE still gets something as well as a notification that it wasn't what they asked for.

Cheers
James

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Thursday, 21 February 2013 10:25 AM
To: Nathan Wilcox
Cc: Rosen, Brian; [email-masked]
Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

Yes.  This.

-Marc-

Dan

-Marc-

Brian

Carry on...

-Marc-

Thanx,
Dan

What am I missing?

-Marc-

Thanx,
Dan

Thanx,
Dan

Regards

Keith

Hello,

Kind regards

Ivo Sedlacek

Dan

Kind regards

Ivo Sedlacek

Thanx,
Dan

Cheers
James

To: Ivo Sedlacek

urn:service:sos.police

Thanx,
Dan