Subject: [Ecrit] comments on LoST

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 11 Jul 2006 01:36:49 -0400

Major:

* LoST doesn't allow for any variability in the format of location 
information. I wonder if it makes sense to include an indication of the 
format of the location object, and to allow rejection if the format is 
not supported. Probably you'd need a baseline for interoperability.

* I dont like how dialstring is added as an attribute of the location 
response, rather than a type of 'service' that you can query for just 
like emergency service. Can't the dial strings have their own 
definitions of regions of coverage that are separate from the region of 
coverage of a psap, for example?

* Its not clear how the region element actual specifies a region when it 
  is composed of a series of civic addresses. What is the algorithm for 
determining whether my current address, expressed in civic coordinates, 
is inside or outside of a region defined that way?

* for dialstrings, suggest perhaps the KPML syntax for digit maps

> 6.6.  Validated Element
> 
>    Each validated element contains a string which is composed by by
>    concatenating the elements from the request which have been
>    recognized as valid by the server.

Very unclear what this means. I read it several times and couldn't make 
sense of it.

> .7.  text Attribute
> 
>    This is a text type suitable for internationalized human readable
>    text.

OK - but what is its semantic?

* It'd be nice to be able, in a single lost query, ask for multiple 
services for the same location

* For list service query: how do I ask for all services? Is it 
"urn:service"? "urn:"? "*"?

* Security aspects are still really weak. You need to specify basic 
proceudres as part of the basic client and server processing. Beyond 
mutual tls I think we want a standard server side authentication 
mechanism as well, with no client authentication

Minor:

* figure 1 makes it look like there are two queries (one that provides 
location, one that proviedes a service URN) followed by two responses. 
I'd suggest a single arrow in each direction

>  LoST supports a query using geospatial and civic location information
>    using the findLoSTByCivic and the findLoSTByGeo query.  Geospatial
>    location information uses GML format [9] and civic location
>    information utilizes the format defined in [10]. 

you need to specify exactly which xml element you are talking abtou in 
both cases.

>  The type of service desired is specified by the <service> element.
>    The emergency identifiers listed in the registry established with [6]
>    will be used in this document.

need to be clear that this is the service URN itself

* LoST talks in a bunch of places about 'call time', but this concept is 
specific to voip and I think LoST has applications beyond just voip. 
Maybe generalize this.

* is xml:lang being used for freeform text fields? I couldn't tell. 
Also, you may want to allow multiple text fields, each in a different 
lanuage, so that client can render the one it understands

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Andrew Newton <[email-masked]>
Date: Tue, 11 Jul 2006 16:02:10 -0400

On Jul 11, 2006, at 1:36 AM, Jonathan Rosenberg wrote:

> information. I wonder if it makes sense to include an indication of  
> the format of the location object, and to allow rejection if the  
> format is not supported. Probably you'd need a baseline for  
> interoperability.

Rejection?  Stating such a thing may be useful during validation, but  
rejection is not a use case.

> * for dialstrings, suggest perhaps the KPML syntax for digit maps

Aren't returned dialstrings to be stuck into tel or sip URIs?  If so,  
would KPML be compatible?

> services for the same location

Given the conversation on multiple locations, I'd prefer we hold off  
on this.  It is nice to have, but keeping complexity down is also a  
nice to have.

> proceudres as part of the basic client and server processing.  
> Beyond mutual tls I think we want a standard server side  
> authentication mechanism as well, with no client authentication

Being able to have that would be nice, but server side authentication  
will not work world wide.  I suppose it would depend on the TLS  
library, but some would require a requery with different options if  
the first query failed due to bad authentication.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 11 Jul 2006 16:35:54 -0400

>would KPML be compatible?
This is a non-trivial issue.

In general, they are dialstrings.  However, what you do with them is to use
them to find the dialstring when entered (and substitute the service urn).
One way to do that is to modify the digit map.

But, in general, that is a VERY hard task - take an arbitrary digit map and
modify it to find the emergency dialstrings, even if they conflict with the
existing dial plan.

So, I don't think you really do that: you don't attempt to modify the digit
map.  You use a totally independent check on entered digits and look for the
strings.  For that, a simple string representation is the best.

You could have two independent KPML digit maps, but I think that is pretty
silly, because it really is a straight string match with a (list of)
dialstring(s).

Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 11 Jul 2006 17:13:01 -0400

> would KPML be compatible?

 From my view, KPML mainly adds the ability to express dial patterns. 
I'm not sure that capability is all that useful for services. Would you 
want to say "dialing any number starting with 9 gets you emergency 
services?" (Obviously, this also increases the mischief potential: "Dial 
[any number] to get to PizzaHouse pizza!")

> Given the conversation on multiple locations, I'd prefer we hold off on 
> this.  It is nice to have, but keeping complexity down is also a nice to 
> have.

To add to this, these services may also have different service areas, so 
you may not save a whole lot of bytes by doing that. Plus, you now have 
much more complicated failures: "Sorry, the third service you specified 
did not exist".  Note that different top-level services can also go to 
different LoST servers, so we now have to worry about people putting 
unrelated services in one query, creating yet another error case.

> will not work world wide.  I suppose it would depend on the TLS library, 
> but some would require a requery with different options if the first 
> query failed due to bad authentication.

I don't see client authentication as particularly helpful in general, 
given that the mapping information is generally public. Server 
authentication would probably generally follow the HTTP(S) model, where 
you might have the same information available in both modes.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 11 Jul 2006 18:05:46 -0400

Some of my thinking is that the scope of LoST isn't JUST emergency 
services. Its not obvious to me that there will NEVER be a 
location-based service that has a digit-map that is more complex than an 
exact match to a fix set of digits.

I wasn't proposing to merge dial plans. I don't think you have to do 
that to use a digit map for emergency services. You would, as you 
suggest, effectively run them in parallel, and if the emergency digit 
map matches before anything configured, use it.

Thanks,
Jonathan R.

---

From: Andrew Newton <[email-masked]>
Date: Wed, 12 Jul 2006 10:26:27 -0400

Responding to my own message since Jonathan and I had a quick  
exchange on this subject in the meeting yesterday...

On Jul 11, 2006, at 4:02 PM, Andrew Newton wrote:
>> * Security aspects are still really weak. You need to specify  
>> basic proceudres as part of the basic client and server  
>> processing. Beyond mutual tls I think we want a standard server  
>> side authentication mechanism as well, with no client authentication
>
> Being able to have that would be nice, but server side  
> authentication will not work world wide.  I suppose it would depend  
> on the TLS library, but some would require a requery with different  
> options if the first query failed due to bad authentication.

Just to be clear, you are suggesting this as MUST implement but not  
MUST deploy, correct?  So long as there is plain HTTP, I see no harm  
in doing this.  I believe client authentication will be difficult to  
achieve in practice, but I see no reason why we can't ask  
implementations to support it since it is a common feature in most  
TLS libraries.

-andy