Re: [Geopriv] Geo in ENUM

[Richard Barnes <rbarnes at bbn.com>]

Alex,

Thanks for your reply.  Given the distinction between location 
configuration and location by reference, I agree that it makes more 
sense to keep these DNS entries distinct.

--Richard



Alexander Mayrhofer wrote:
>> I just saw your document in ENUM proposing a location ENUM 
>> service.  Why 
>> is this necessary in addition to the U-NAPTR mechanism in the LIS 
>> discovery document?  (draft-ietf-geopriv-lis-discovery)  It 
>> seems like 
>> you could just one of the U-NAPTR records as defined there with an 
>> e164.arpa domain to do what you're doing.  Is there something special 
>> about the e164.arpa domain that requires a separate NAPTR mechanism?
> 
> Hello Richard,
> 
> i've reviewed the LIS Discovery draft, and it has a very different use
> case from what i'm trying to achieve with the "Geo" ENUM service.
> 
> The LIS discovery draft says in the introduction that the URI retrieved
> can jsut be used for location configuration of the requestor, not as a
> location by reference URI. That's exactly the contrary of what i'm
> trying to achieve with the ENUM-Service: The ENUM service is supposed to
> carry a location-by-reference URI for the device that uses the
> corresponding phone number, and that URI would not be used for location
> configuration.
> 
> 
> This might be useful in a scenario like this:
> 
> - Carrier A delivers an emergency call to a PSAP using "normal" PSTN
> transport.
> - PSAP receives only the number, but can "look up" the
> location-by-reference URI by means of an ENUM tree (that tree may very
> likely be private to carriers and PSAPs)
> - PSAP dereferences location-by-reference URI gathered from ENUM.
> 
> Another scenario might be a quite "open" scenario, like:
> 
> - I configure the location-by-reference URI into my public ENUM entry.
> - everybody can look up that ENUM entry by my phone number
> - However, i limit location dereferencing to "people i know".
> 
> Hope that made the difference in use cases (compared to the
> lis-discovery draft) clear.
> 
> (BTW, small nit - i've not read the held: URI spec, but you say in
> section 2 that there "is no default port", while the port component is
> not included in the example URI in section 4)
> 
> 
> Alex
> 
_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www.ietf.org/mailman/listinfo/geopriv