Re: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-06.txt

[Dan Banks <[e-mail]>]

I am happy to see that many of the issues I previously noted have been addressed in the latest draft.  There are some things that I believe still need attention:

As previously noted, the schema defines groups named "similarLocation" and "completeLocation", but this does not actually define the elements having those names.  As far as I can tell, there is nothing in the schema that defines these actual elements as they appear in the examples.  Instead, the schema appears to only add a sequence of <location> elements at the locationValidation extension point, followed by another extension point (which would be redundant).  Except I'm not even sure that is correct without including the LoST namespace in the ref="location".  (similarLocation also adds the similarLocationsLimited attribute, which I believe would apply to the locationValidation element directly as it is currently defined).

The location in the request in the example in section 5.2 was replaced with a location having fully spelled values, which I had asked for.  However, it includes the prefix "ca:" in front of the elements, which is not defined in that particular document.  These prefixes can be removed in this request because the parent civicAddress element declares the correct xmlns= attribute (the response is correct in the way it uses the prefixes).

The location of the request in the example in section 5.1 was not updated, but I believe it should have been.  It also has a namespace prefix problem with the country element.  Also, whitespace should be added between the validationLocation and returnAdditionalLocation attributes in this request.

In the response in the example in section 5.1, the profile attribute was added as suggested, however it is incorrectly shown outside of the completeLocation element tag.  It is shown correctly in the response in 5.2.

returnAdditionalLocation was made an attribute as I requested.  It is declared in the lost-rli1 target namespace, which I believe is the way we want to do it, but appears in the examples without a namespace.  In the example in 5.2, it appears in the location element instead of in the findService element.

Here is an attempt at correcting the request for 5.2 considering the issues above:

<findService xmlns="urn:ietf:params:xml:ns:lost1"
  xmlns:rli="urn:ietf:params:xml:ns:lost-rli1"
  validateLocation="true"
  rli:returnAdditionalLocation="any">
  <location id="587cd3880" profile="civic">
    <civicAddress
      xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
      <country>US</ca:country>
      <A1>WA</A1>
      <A2>KING COUNTY</A2>
      <A3>SEATTLE</A3>
      <RD>15TH</RD>
      <STS>AVENUE</STS>
      <HNO>6000</HNO>
      <PC>98106</PC>
      <PCN>SEATTLE</PCN>
    </civicAddress>
  </location>
  <service>urn:service:sos</service>
</findService>


Dan


-----Original Message-----
From: Ecrit <[e-mail]> On Behalf Of [e-mail]
Sent: Tuesday, October 23, 2018 4:40 PM
To: [e-mail]
Cc: [e-mail]
Subject: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-06.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Emergency Context Resolution with Internet Technologies WG of the IETF.

        Title           : A LoST extension to return complete and similar location info
        Authors         : Roger Marshall
                          Jeff Martin
                          Brian Rosen
	Filename        : draft-ietf-ecrit-similar-location-06.txt
	Pages           : 17
	Date            : 2018-10-23

Abstract:
   This document introduces a new way to provide returned location
   information in LoST responses that is either of a completed or
   similar form to the original input civic location, based on whether
   valid or invalid civic address elements are returned within the
   findServiceResponse message.  This document defines a new extension
   to the findServiceResponse message within the LoST protocol [RFC5222]
   that enables the LoST protocol to return a completed civic address
   element set for a valid location response, and one or more suggested
   sets of similar location information for invalid LoST responses.
   These two types of civic addresses are referred to as either
   "complete location" or "similar location", and are included as a
   compilation of CAtype xml elements within the existing LoST
   findServiceResponse message structure.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ecrit-similar-location-06
https://datatracker.ietf.org/doc/html/draft-ietf-ecrit-similar-location-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-similar-location-06


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit