Subject: [Ecrit] draft-ietf-ecrit-similar-location-03 feedback - additional

From: Dan Banks <[email-masked]>
Date: Mon, 17 Oct 2016 20:18:45 +0000

There is one thing I would like to add to the feedback which I sent recently on the similar location draft:

Section 4 discusses briefly the possibility of the server limiting the number of returned similar locations.  Although the current text expresses the general idea that there may be a few that are the "most likely" to be the correct location, there are also scenarios where many similar locations could all be equally likely, and the server might need to simply cut off the list at a reasonable count.  In those situations, I believe it would be helpful if the server indicated when such  a limit is actually applied.

I suggest that an attribute be added to the locationValidation element of the findService response, perhaps rli:similarLocationsLimited, having a data type of boolean, with instructions that a server SHOULD include this attribute if the number of returned similar locations is limited due to configuration or policy.

Dan Banks

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 17 Oct 2016 20:24:23 +0000

I don’t really have a problem with having this option, but one question I have is what would the client do with that information?  I can’t think of any behavior change that return of that information would trigger.

Brian

From: Dan Banks <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 17, 2016 at 4:18 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Brian Rosen <[email-masked]<mailto:[email-masked]>>
Subject: draft-ietf-ecrit-similar-location-03 feedback - additional

Section 4 discusses briefly the possibility of the server limiting the number of returned similar locations.  Although the current text expresses the general idea that there may be a few that are the “most likely” to be the correct location, there are also scenarios where many similar locations could all be equally likely, and the server might need to simply cut off the list at a reasonable count.  In those situations, I believe it would be helpful if the server indicated when such  a limit is actually applied.

Dan Banks

---

From: Dan Banks <[email-masked]>
Date: Mon, 17 Oct 2016 21:45:45 +0000

I’m thinking of an example where you might a large apartment building, and a query that did not include unit or floor.  If the response only lists the first 5 units as similar locations, a person looking at this might (incorrectly) assume that the server doesn’t have data for the other 13 units in that building.  Of course, there is already a good disclaimer in the draft not to make such assumptions, but the more often we can give the users a complete list of similar locations, the more effective this extension will be.  So, I think an explicit indication will be helpful.  At the very least, it should save a support call or two (“If the LVF knew that unit 501 was valid, then why did it only suggest 101, 103, 201, 202, and 203?”)

Dan

From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, October 17, 2016 4:24 PM
To: Dan Banks; [email-masked]
Subject: Re: draft-ietf-ecrit-similar-location-03 feedback - additional

Brian

Dan Banks

---

From: Randall Gellens <[email-masked]>
Date: Mon, 31 Oct 2016 11:06:18 -0700

Instead of a boolean, it might be worth considering an integer, to 
inform the client how many similar locations could match.  Depending 
on the situation, the client might report an error and attempt to get 
a less ambiguous location.

At 9:45 PM +0000 10/17/16, Dan Banks wrote:

>  I'm thinking of an example where you might a large apartment 
> building, and a query that did not include unit or floor.  If the 
> response only lists the first 5 units as similar locations, a 
> person looking at this might (incorrectly) assume that the server 
> doesn't have data for the other 13 units in that building.  Of 
> course, there is already a good disclaimer in the draft not to make 
> such assumptions, but the more often we can give the users a 
> complete list of similar locations, the more effective this 
> extension will be.  So, I think an explicit indication will be 
> helpful.  At the very least, it should save a support call or two 
> ("If the LVF knew that unit 501 was valid, then why did it only 
> suggest 101, 103, 201, 202, and 203?")
>
>  Dan
>
>  I don't really have a problem with having this option, but one 
> question I have is what would the client do with that information? 
>  I can't think of any behavior change that return of that 
> information would trigger.
>
>  Brian
>
>  From: Dan Banks <<mailto:[email-masked]>[email-masked]>
>  To: "<mailto:[email-masked]>[email-masked]" 
> <<mailto:[email-masked]>[email-masked]>
>  Cc: Brian Rosen <<mailto:[email-masked]>[email-masked]>
>  Section 4 discusses briefly the possibility of the server limiting 
> the number of returned similar locations.  Although the current 
> text expresses the general idea that there may be a few that are 
> the "most likely" to be the correct location, there are also 
> scenarios where many similar locations could all be equally likely, 
> and the server might need to simply cut off the list at a 
> reasonable count.  In those situations, I believe it would be 
> helpful if the server indicated when such  a limit is actually 
> applied.
>
>  I suggest that an attribute be added to the locationValidation 
> element of the findService response, perhaps 
> rli:similarLocationsLimited, having a data type of boolean, with 
> instructions that a server SHOULD include this attribute if the 
> number of returned similar locations is limited due to 
> configuration or policy.
>
>  Dan Banks
>
>  _______________________________________________
>  Ecrit mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/ecrit

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Don't worry about what people think; they don't do it very often.