Thanks for the review. See inline. > On Feb 25, 2022, at 2:26 PM, Tatuya Jinmei via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Tatuya Jinmei > Review result: Ready > > I am an assigned INT directorate reviewer for > <draft-ietf-ecrit-similar-location-18.txt>. These comments were written > primarily for the benefit of the Internet Area Directors. Document editors and > shepherd(s) should treat these comments just like they would treat comments > from any other IETF contributors and resolve them along with any other Last > Call comments that have been received. For more details on the INT Directorate, > see https://datatracker.ietf.org/group/intdir/about/ > <https://datatracker.ietf.org/group/intdir/about/>. > > This draft defines a few optional extensions to the LoST protocol as defined in > RFC5222 so that the server can provide supplemental information that may be > useful for the client. I'm not familiar with the LoST protocol, so it's quite > possible my review miss something. With noting that, the draft is very well > written, its purpose and explanations are clear, and I didn't find any obvious > problem, especially those related to the INT area. I think it's ready for > publication. > > I have a couple of comments, making mostly just out of curiosity. I'd be happy > to get clarifications on these points, but these are not blocking issues at all. > > - The definition of similarity (in Section 2) looks loose to me: > > Similar Location: A suggested civic location that is similar to an > Invalid Location which was used in a LoST query, but which has one > or more elements added, modified, or removed such that the > suggested location is a Valid Location. > > If we apply this definition literally, a completely "different" location > could be considered to be "similar" as long as it's valid, since all > editorial operations can be applied for arbitrary times, right? Perhaps it's > intentionally kept loose and left to the server implementation and > discretion, but it would be also nice if it gives some example of what would > NOT be considered to be similar (for example, what if an element contains a > misspelling and fixing it would make it valid?). The server can’t know what the intended location is. So it very well could be different in the sense you mean. Yes, it is intended to be loose, because the server might use all kinds of info that isn’t specified: think about an AI that looked at all the invocations of the command, and subsequent validations, to see how it’s advice was used and tuned the advice accordingly. It is, by definition, guessing. We don’t say how wild a guess it can make, or not make. A misspelled word is an excellent example of what it could be used for: suppose the postal code was specific enough to see that it likely was a misspelled municipality name. Perfectly reasonable Similar location. The original has municipality on the <invalid> list, and all the other lower level submitted fields on the <unchecked> list. The Similar Location has all the same fields with the correct municipality (A3). > > - Also related to the above definition, can "Similar Location" be used only > when the input is invalid? For example, what if both "6000 15th Avenue > Northwest" and "6000 15th Avenue Southwest" exist and the input is either of > them in a complete form, can we include the other as a "Similar Location”? The text describes the use case when the input If you had a valid location in the input, then you can’t get a field with a different value in Similar Location. You can get Similar Location, but it would have additional fields that were not in the input. Looking at the text, we could make that more clear. Brian -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
