[Ecrit] John Scudder's No Objection on draft-ietf-ecrit-similar-location-18: (with COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-ecrit-similar-location-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. In Section 4 you have

   Clients can control the return of additional location information by
   including the optional 'returnAdditionalLocation' attribute with
   possible values 'none', 'similar', 'complete' or 'any'.  The value
   'none' means to not return additional location information, 'similar'
   and 'complete' mean to only return the respective type of additional
   location information (if the server could send any) and 'any' means
   to include Similar and/or Complete Location (if the server could send
   any).

I don’t know if extensibility is a consideration for you at all, but if it is,
might it be appropriate to tweak the definition of ‘any’ slightly? As written,
if the returnAdditionalLocation attribute were later extended to have the
additional possible value ‘sporcle’, a request for ‘any’ from a strictly
compliant implementation would still presumably only return Similar and/or
Complete but not Sporcle results.

(The fact I can’t think of a non-silly example may suggest that this point is
moot.)

2. In Section 5.2, I’m confused. Surely (or SHIRLEY) that query and response
can’t be right? I expected it to match the second example given in Section 3,
but it doesn’t at all. Nor do the purported similarLocations seem to match the
query very well (they differ in much more than just POD, for example the
countries of the two similarLocations differ and of course one differs from the
country of the query. And now my head is spinning with the plate tectonic
implications of Queensland and Washington State colliding.

Nits:

   (county) and <PC> (Postal Code) Civic Address Elements.  In this
   example, too, the LoST server is able uniquely locate the intended

“is able” -> “is able to”