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

[Randall Gellens <[e-mail]>]

I apologize for the delay.  I've finished a thorough read-through of the 
latest draft and have the following change notes:

(1) In the definition of 'Invalid Location', the fourth line starts with 
"that It is".  The word "it" should not be capitalized.

(2) Section 3, first paragraph, consider changing "As of this document" 
to "As of this document's publication".

(3) Same paragraph, consider changing "describes the returned location 
extension primarily in terms of how it is used with the" to "describes 
the extension using the".

(4) Section 3, third paragraph starting "In a LoST findServiceResponse", 
I suggest enclosing "findServiceResponse" in angle brackets.

(5) Same paragraph, I think it would be more clear to change "a 
<locationValidation>" to "the <locationValidation>" because otherwise it 
sounds like an additional <locationValidation> might be included.

(6) Same paragraph, I find the text describing the example confusing.  
Maybe I'm misreading it, but it seems to starts out describing an 
example where <POD> is needed, but then it says that other entities 
might want <A2> and <PC>.  If I'm reading it correctly, it seems to be 
describing two examples, one where the address is only borderline valid 
but still sufficient to be uniquely identified, and another where an 
address is more clearly valid but missing two elements that should be 
there for completeness.  I suggest breaking this into two examples and 
also rewording the material as follows:

Change:

    As an
    example, the query might contain <HNO> (house number), <RD> (road
    name) <A3> (city), <A1> (state/province) and a few more CAtype
    elements, but might not contain <POD> (Post-Directional) or <PC>
    (Postal Code) CAtype elements.  In this example, there is no street
    with just the streetname, all streets have a post-directional.  The
    civic location in the request might contain <HNO>, <RD>, <STS>, <A3>
    and <A1> Civic Address Elements that are sufficient enough for the
    LoST server to uniquely locate the address specified in the request
    and thus be considered Valid, meaning there was only one street with
    the house street name and house number in the city that it could be.
    Yet, other entities involved in a subsequent emergency call might
    find it helpful to have additional Civic Address Elements such as
    <A2> (county) and <PC> (Postal Code) included as part of a complete
    civic location.

To:

    As an example, a query contains <HNO> (house number), <RD> (road
   name) <A3> (city), <A1> (state/province) but not <POD>
   (Post-Directional).  In this example, there is no street with just
   the street name, all streets have a post-directional.  However, the
   LoST server is able to uniquely locate the intended address and
   thus consider the queried location Valid, as there is only one
   street with the street name and house number in the city
   that it could be.  As the queried location is missing the
   post-directional element, a more strict entity might consider it
   Invalid (e.g., during a subsequent query) or worse, the lack of
   a Post-Directional element might cause confusion and delay
   an emergency response.  The server can use this extension to
   supply the missing post-directional element <POD> in a
   <completeLocation> element within the <locationValidation>
   element.

    In another example, the civic location in a request might lack
    <A2> (county) and <PC> (Postal Code) Civic Address Elements.  In
    this example, too, the LoST server is able uniquely locate the
    intended address and consider the location <Valid>, but other
    entities involved in a subsequent emergency call might find it
    helpful to have the additional Civic Address Elements.  The LoST
    server can use this extension to supply the missing <A2> and <PC>
    Civic Address Elements.

(7) Section 3, fifth paragraph, there is an example addresses shown in 
colloquial form (not in Civic Address elements).  I suggest adding a 
comma before the city.

Change:

    Input address: 6000 15th Avenue Seattle, WA US	
  		
    Complete Location: 6000 15th Avenue Northwest Seattle, WA 98105 US

To:

   Input address: 6000 15th Avenue, Seattle, WA US

   Complete Location: 6000 15th Avenue Northwest, Seattle, WA 98105 US


(8) In Section 3, eight paragraph, second line, starting with "request 
contains Invalid Location", should this be "an Invalid Location"?

(9) Following paragraph, third line, I suggest changing "was sufficient" 
to "is sufficient".

(10) Following line, I suggest changing "In that case" to "in this case" 
and change "would be listed" to "is listed".

(11) Same text, should "just as in the above example" be changed to 
"just as in the above example the missing <A3> element is included in a 
<completeLocation> element"?

(12) Following paragraph, consider rewording the run-on sentence that 
starts the paragraph.

Change:

    As another example of the use of <similarLocation>, consider the
    results based on a similar data set as used above, where the <HNO>,
    <RD>, <STS>, <A1>, and <A3> Civic Address Elements are not 
sufficient
    to locate a unique address, which leads to an invalid location 
result
    because the LoST server contains additional civic address elements
    which would have resulted in a uniquely identifiable location if
    these additional elements had been included in the location sent in
    the query.

To:

    As another example of the use of <similarLocation>, consider the
    results based on a similar data set as used above, but where the
    <HNO>, <RD>, <STS>, <A1>, and <A3> Civic Address Elements are not
    sufficient to locate a unique address, resulting an invalid
    location response.  Because the LoST server contains additional
    civic address elements which, had they been included in the
    query,  would have resulted in a uniquely identifiable location,
    the server can include one or more <similarLocation> elements
    containing the supplied Civic Address Elements plus the omitted
    ones.

(13) Same paragraph, near the end, I suggest deleting "message" from 
"the <findServiceResponse> message".

(14) Following paragraph, I suggest enclosing "findService" in angle 
brackets in "findService request:".

(15) In the following paragraph (the 13th, I think) I suggest adding a 
comma after the street Post-Directional in the colloquial form example 
addresses.

Change:

   Input address: 6000 15th Avenue North Seattle, WA US

To:

   Input address: 6000 15th Avenue North, Seattle, WA US

(15) Same section, 15th and 16th paragraphs, I suggest adding a comma 
after the street Post-Directional in the colloquial form example 
addresses (as above).

Change:

    Similar address #1: 6000 15th Avenue Northwest Seattle, WA 98107 US

    Similar address #2: 6000 15th Avenue Northeast Seattle, WA 98105 US

To:

    Similar address #1: 6000 15th Avenue Northwest, Seattle, WA 98107 US

    Similar address #2: 6000 15th Avenue Northeast, Seattle, WA 98105 US

(16) In the first paragraph of Section 4, there's a typo where 
"<civicAddressgt;" appears (an improperly opened entity name).  This is 
corrected in the suggested replacement text of item (17).

(17) In Section 4, the text states that <completeLocation> and 
<similarLocation> elements "contain location information in the same 
profile of the location used to answer the query."  Isn't 'profile' an 
attribute of both elements, and shouldn't the text say that the 
'profile' attribute must be set to the same value as the profile of the 
queried location, or, to be more similar to how RFC 5222 treats 
<serviceBoundary>, if one or more <completeLocation> or 
<similarLocation> elements are included in the response, at least one 
must be use the same profile as the request (which would allow a server 
to include, e.g., two <completeLocation> elements, one in the profile of 
the request and one in a different profile (if/when additional civic 
profiles are defined)?

Change:

    The
    <completeLocation> and <similarLocation> elements are of type
    "locationInformation" as defined by the LoST schema in [RFC5222], 
and
    contain location information in the same profile of the location 
used
    to answer the query.  These elements MAY contain location 
information
    either in the Basic Civic profile defined in RFC5222 or in another
    profile derived from the Basic Civic profile whose definition
    provides instructions concerning its use with this extension.  When
    used with the Basic Civic profile, these elements contain a
    <civicAddressgt; element as defined in [RFC5139].

To either:

    The <completeLocation> and <similarLocation> elements are of type
    "locationInformation" as defined by the LoST schema in [RFC5222].
    These elements MAY contain location information either in the
    Basic Civic profile defined in RFC5222 or in another profile
    derived from the Basic Civic profile whose definition provides
    instructions concerning its use with this extension, but this
    MUST be the same profile as the location in the query.  When used
    with the Basic Civic profile, these elements contain a
    <civicAddress> element as defined in [RFC5139].

Or:

    The <completeLocation> and <similarLocation> elements are of type
    "locationInformation" as defined by the LoST schema in [RFC5222].
    These elements MAY contain location information either in the
    Basic Civic profile defined in [RFC5222] or in another profile
    derived from the Basic Civic profile whose definition provides
    instructions concerning its use with this extension.  A response
    MAY include more than one <completeLocation> or <similarLocation>
    elements containing the same address expressed using different
    profiles, but at least one MUST use the same profile as the
    request.  When used with the Basic Civic profile, these elements
    contain a <civicAddress> element as defined in [RFC5139].

(18) If we go with the second option of (17), to explicitly allow 
multiple <similarLocation> or <completeLocation> elements that express 
the same location in different profiles, for clarity we should change 
the second paragraph of Section 4:

Change:

    more than one <similarLocation> element

To:

    more than one <similarLocation> element expressing different 
locations

(19) If we go with the second option of (17), to explicitly allow 
multiple <similarLocation> or <completeLocation> elements that express 
the same location in different profiles, for clarity we should change 
the third paragraph of Section 4:

Change:

    MAY include a <completeLocation>
    element

To:

    MAY include a <completeLocation> element (or multiple elements
    containing the same location using different profiles)

(20) In the last paragraph of Section 4, I suggest rewording the text to 
avoid any confusion over possible future profiles (since the document 
says earlier that profiles other than 'civic' in RFC 5222 may be defined 
that specify how they are used with this extension).

Change:

    in a profile derived from the 'civic' profile

To:

    in a profile other than the 'civic' profile

(21) I suggest changing the name of Section 5.1 for clarity, either keep 
"response" and change "for" to "in", or delete "response":

Change:

    Complete Location returned for Valid Location response

To either:

    Complete Location returned in Valid Location response

Or:

    Complete Location returned for Valid Location

(Personally, I think the latter reads slightly better.)


(22) In the first paragraph of Section 5.1, I suggest rewording for 
easier reading:

Change:

    Based on the example input request above, Returned Location
    Information is provided in a <findServiceResponse> message since the
    original input address is considered valid but is missing some
    additional data that the LoST server has.

To:

    This example is based on the example request above; the LoST
    server considered the location in the query to be valid but
    missing some Civic Address elements, so in the Returned Location
    Information in the <findServiceResponse>, the server includes a
    <completeLocation> element supplying the omitted Civic Address
    elements <A2>, <PC>, and <PCN>.


(23) (21) I suggest changing the name of Section 5.2 for clarity, as 
with 5.1, by either keeping "response" and changing "for" to "in", or 
deleting "response":

Change:

    Similar Location returned for Invalid Location response

To either:

    Similar Location returned in Invalid Location response

Or:

    Similar Location returned for Invalid Location

(Personally, I think the latter reads slightly better.)


(24) In the first paragraph of Section 5.2, I suggest slight rewording:

Change:

    two returned Similar Locations in a

to:

    two Similar Locations returned in a







--Randall