|
|
I would say that the service URN defines what service location based routing
is needed for. I don't think it should be up to ecrit to define which
services location based routing is needed. We're defining a mechanism: put
in location and service type (URN) and get out URIs. That's enough for
ecrit.
We can try to make the organization of the service URN tree structure
reflect some sort of common reality, but we are highly unlikely to be always
right all of the time. I think it would be a mistake to try to infer any
kind of policy decision by the shape of the "urn:service." tree.
I don't think that matters. It can be a local policy (or maybe a policy
that is associated with the dialstring that is mapped to the service URN)
whether this is an "emergency", whether location is forwarded, etc at the
location the call originates from.
Brian
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@xxxxxxxxxx]
Sent: Tuesday, May 16, 2006 9:10 AM
To: Henning Schulzrinne
Cc: Stastny Richard; ecrit@xxxxxxxx
Subject: Re: [Ecrit] Re: Commments I.D-ecrit-service-urn-03 Child helpline
Let's back off a moment and consider what this is for. The purpose of
the service URN, as far as ECRIT is concerned, is to provide an
unambiguous indication that the call should be routed to a PSAP. It's
all very well to have attributes whose treatment is defined by local
policy, but what about the proxy half-way around the world that has to
recognize an emergency call?
Henning Schulzrinne wrote:
>>> One pretty simple solution is to have a four-valued attribute:
>>> - required --> no service without it; you're legally obligated to
>>> provide it for this service
>>> - helpful --> the receiver would like to have this information,
>>> but isn't going to refuse the call and you're not legally
>>> obligated; if you route the call yourself, you don't need to
>>> include it in signaling
>>> - routing --> the receiver doesn't need it, but it's used to
>>> route the call
>>> - ignored --> the receiver will just ignore the location
>>> information and there's no location-based routing
>>> I suspect this can be split into two dimensions (routing and end
>>> system).
>> Does not sound like a bad idea.
>> This assumes that these properties do not change on a regular basis
>> or depend on parameters that cannot be provided by LoST (e.g., user
>> specific properties).
>>
>
> I suspect that these attributes would be governed by national or
> state laws and regulations, which presumably change slowly and with
> advance notice, well outside the anticipated caching intervals for
> LoST records.
>
>
>> What do other people think?
>>
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ecrit
>
>
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|