Re: [Ecrit] country specific emergency URNs

[Georg Mayer <[e-mail]>]

Hello,

coming late to this discussion, just a few comments.

1) if the name holds no meaning but should be suggestive, then the most
suggestive name I could think of e.g. in Austria would simply be the
number that you call today. But then we are back at square one again, as
I guess the idea (once at least) was to avoid numbers.
What I want to say: if the name really does  not hold any
meaning/semantics, then it will be hard to deny anybody to register any
URN-name for a specific service.

2) In the counseling example (just taken as an example) I think the
situation is really much more complicated. You just don't want to hand
out a URN that says christian.counseling - I can see even problems
within single countries. You will end up with a long looong list of very
specific services and it will be hard to keep the overview.
It might be easier to just have them country specific, then things a
clearer.

Again, semantics plays a role here and people read it from the URN.

3) Compiling the list - that's an effort that will most likely never
end. And it is also something that seemingly nobody wants to do - its
much more work then just putting together all the numbers and the
person/organization which then merges  the different services will for
sure be criticized from different sides.
In my opinion the national legislations should take responsibility on
this and we should not try to negotiate between them. We should give
them a vehicle that allows them to easily register their related services.

In any way, I don't think that from 3GPP side we can come up with a full
list. It might be that GSMA can start such an initiative, but regardless
of who is doing this, it would create an enormous overhead, which in my
eyes is unnecessary.

Cheers,
Georg

On 2017-07-12 21:57, Brian Rosen wrote:
>> If that is true, we do we separate the sub-services to begin with? Why
>> do we define sub-service specific registration procedures (even though
>> they happen to be identical for the existing sub-services?
> Because we would like the name to be suggestive of the function so that
> provisioning and debugging is easier.  That really is why we did it that
> way.  Using a GUID would have worked.
> 
>>  
>> RFC 5031 defines semantics for the sos sub-service, and at least my
>> understanding is that sos is to be used for emergency services, and
>> nothing else. 
> There is no limit expressed, or implied, that sos is restricted to
> “flashing lights” emergencies.  It’s suggestive of emergency, but not
> exclusively used that way.  The counter example was the non-emergency
> ambulance service.  Using sos.ambulance for a non emergency ambulance
> service, unless a country has both an emergency and a non-emergency
> ambulance service that needs urns, is appropriate I think.  I don’t
> think it would be wrong to create a non-emergency ambulance
> registration, but I also don’t think we need to.
> 
>> Where is it said that it is ok to use sos also for non-emergency
>> services, and to use non-sos for emergency services?
> There is no MUST language at all.  Anything is acceptable, although the
> expert review gets to offer an opinion, and take it to the list if
> needed.  The review is merely supposed to make sure the service is
> distinct from an existing registration.  Registrations are cheap.
> 
>>  
>> If we start using non-sos for emergency services, and sos for
>> non-emergency services, I think we will end up in a mess…
> The above example is how I think we don’t get into a mess.  I don’t
> think there is a good reason to create an ambulance service that isn’t
> in the sos tree unless we have an incidence of two services and we need
> to differentiate.  Even if the ambulance service in a country is not
> considered an emergency service, using sos.ambulance for it is fine in
> my opinion.
> 
> 
>>  
> 
> 
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
> 

-- 
Georg Mayer
3GPP CT Chairman
HUAWEI Technologies
Mobile: [phone]