Subject: [Ecrit] Local-Civic and LoST

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 12 Oct 2011 10:42:23 +0800

Hi All,

At the last IETF meeting we reached a consensus call on what was thought to be the remaining issue with the local-civic specification (http://tools.ietf.org/html/draft-ietf-geopriv-local-civic-01). This issue was to do with the registration of extended CAtypes and their associated namespaces. This issue was resolved through consensus and we have a good write up on it.

Local-civic has some impacts on LoST implementations, most notably when LoST is used for civic location validation. When used in this manner the LoST server returns a set of qualified civic address elements that it has found to valid, invalid or hasn't checked. The example in figure 6 of RFC5222 does not show these civic address elements as being qualified and this gave rise to an errata (http://www.rfc-editor.org/errata_search.php?rfc=5222) that points this out.

After some discussion on the ECRIT list, the errata has been moved to a state of "Held for document update", and this is largely because it was deemed that the proposed errata correction requires some kind of consensus call.

It has been proposed that since local-civic depends on the errata, that local-civic could normatively update LoST to point out a corrected example and hence mandate that all these civic elements be qualified in future. I think that this is quite a good idea, and propose the addition below to the local-civic draft, but I would like to get feedback from both ECRIT and GeoPriv on their views.

Cheers
James

6.  Using Local Civic Extension with the LoST Protocol

   One ciritical use of civic location information is in next generation

   emergency services applications, in particular call routing

   applications.  In such cases location information is provided to

   location-based routing service using the location to service

   transtion (LoST) protcol [RFC5222].  LoST is used to provide call

   routing information, but it is also used to validate location

   information to ensure that it can route to an emergency center when

   required.

   LoST is an XML-based protocol and so the namespace extension

   mechansims described in this document do not impact LoST.  When LoST

   is used for validation a <locationValidation> element is returned

   containing a list valid, a list of invalid, and a list of unchecked

   civic elements.  Figure 6 is an extract of the validation response in

   Figure 6 from [RFC5222].

   <locationValidation>

       <valid>country A1 A3 A6</valid>

       <invalid>PC</invalid>

       <unchecked>HNO</unchecked>

   </locationValidation>

         Figure 6: Location Validation Example from LoST (RFC5222)

   The RelaxNG schema in [RFC5222] requires the elements in each of

   these lists to be namespace qualified, which makes the example in

   Figure 6 from [RFC5222] in error.  This issue is especially

   significant when local-civic extensions are used as the domain to

   which the extensions are attributed may impact their interpretation

   by the server or client.  To ensure that local-civic extensions do

   not cause issues with LoST server and client implementations, all

   elements listed in a <valid>, <invalid>, or <unchecked> element MUST

   be qualified with a namespace.  To illustrate this the extract above

   from figure 6 in [RFC5222] becomes Figure 7.

   <locationValidation

          xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">

       <valid>ca:country ca:A1 ca:A3 ca:A6</valid>

       <invalid>ca:PC</invalid>

       <unchecked>ca:HNO</unchecked>

   </locationValidation>

              Figure 7: Corrected Location Validation Example

   If validation request has also included the extensions defined in

   section Section 5 then the validation would response would look like

   Figure 8.

 <locationValidation

        xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"

        xmlns:cae="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext">

     <valid>ca:country ca:A1 ca:A3 ca:A6 cae:PN cae:STP</valid>

     <invalid>ca:PC</invalid>

     <unchecked>ca:HNO cae:MP cae:HNP</unchecked>

 </locationValidation>

              Figure 8: Corrected Location Validation Example

James Winterbottom
Global Product Manager
Commscope GeoLENs
IP Location Product Portfolio
Andrew Building (39), University of Wollongong
Northfields Ave, Wollongong, NSW, 2522 Australia
Email: [email-masked]<mailto:[email-masked]>
Phone: +61-2-42-212938
Mobile: +61-447-773-560
www.commscope.com<http://www.commscope.com/> | www.commscopeblogs.com<http://www.commscopeblogs.com/>