Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated

[Randall Gellens <[e-mail]>]

Let me try this again.

What the text says now:

3.  <plannedChange> element

    The URI will be stored by the server against the location in the
    request

4.  <locationInvalidated> object

    When the server needs to invalidate a location where the client
    provided a URI in <plannedChange>,
...
    The LoST server is NOT REQUIRED to store the Location Information
    supplied in the original findService request.  This means the server
    may not know if a planned change will in fact invalidate the 
location
    stored in the LoST client, because changes could be made in the LoST
    server that do not affect validation of the Location Information.
    The LoST client may find that upon revalidation with the changed

I had misunderstood this to mean that the server could store the URI in 
any way it wants, and so the server may not know if a change to some 
location information that it has configured would invalidate a location 
for which it stored a URI.  You clarified in email that your intent is 
to constrain the server so that a notification is only triggered for a 
change to the underlying location information, even if that change 
doesn't invalidate the specific location of the query.  Based on this, I 
think we need clarifying text to better explain this (to help a reader 
understand the intent), and also some normative language added regarding 
the server, to the effect that if it decides to store the URI, it needs 
to store it associated with something that if it changes, the location 
in the query is or is likely affected, even if not invalidated.  We 
obviously don't constrain LoST server implementations, they can store 
data in any way they like (we only specify a configuration interface in 
LoST-sync and of course the query interface in LoST).  But if we want 
the draft to reflect your intent, I think we need some kind of normative 
text about what the server stores.

--Randall

On 23 Aug 2021, at 17:03, Brian Rosen wrote:

> I think the text is clear as is: the server doesn’t save the LI, and 
> consequently a change could occur that wasn’t in the LI and still 
> cause a notification.  Again, for US addresses, we have rules about 
> how validation is done that limit how often this could happen.  NAM is 
> an example.  It’s not defined, but it could occur in the LoST server 
> data.  If it did, and it was not sent in the LI of a LoST findService, 
> and it was subsequently changed in the LoST server, there could be a 
> notification.  But other countries could have profiles that, for 
> example explicitly ignore Neighborhood - any value is valid regardless 
> of what is in the server’s data.  They may send unchecked for such 
> cases.
>
> The implementation for this is simple - revalidate and allow the 
> result to be valid without choking.  I’m just trying to make sure 
> the client doesn’t assume that if they revalidate it is guaranteed 
> to fail.
>
> Brian
>> On Aug 23, 2021, at 7:37 PM, Randall Gellens 
>> <[e-mail]> wrote:
>>
>> You mean if only the NAM field changes? Such as if there's a civic 
>> address with NAM but no other address elements, and NAM changes? Or a 
>> civic address with NAM as well as other elements sufficient to form a 
>> valid address on their own?
>>
>> What text would you add to the document to make it clear under what 
>> circumstances a LoST server might save a URI and know that the 
>> location in the query might be invalidated but not know for sure?
>>
>> --Randall
>>
>> On 23 Aug 2021, at 16:11, Brian Rosen wrote:
>>
>> Anything that shows up on the unchecked list.  An example might be 
>> the NAM element,   The US has pretty tight rules on this, so it 
>> really would only be for things like NAM if you had no elements on 
>> the invalid list.  But other countries may not have as stringent 
>> rules as the US on how the invalid/unchecked lists are populated.
>>
>> Brian
>>
>>> On Aug 23, 2021, at 6:29 PM, Randall Gellens 
>>> <[e-mail] <mailto:[e-mail]>> 
>>> wrote:
>>>
>>> I interpreted it as allowing a server to save URIs but for an 
>>> approximate location rather than an exact one, or not associated 
>>> with a location, and hence it would send a notification if a change 
>>> might invalidate the location in the query that supplied the URI. If 
>>> that's not what we mean, then let's be explicit about what we do 
>>> mean. Under what circumstances would a LoST server save a URI and 
>>> know that the location in the query might be invalidated but not 
>>> know for sure?
>>>
>>> --Randall
>>>
>>> On 23 Aug 2021, at 15:22, Brian Rosen wrote:
>>>
>>> The MAY is because it may not allow/have room/… for the URI (or 
>>> not implement it).  If you think the text would allow it, for 
>>> example, to send a notification where some location other than the 
>>> one the URI was sent on changed, then I would like to prohibit that. 
>>>  I especially don’t want a lazy server sending notifications all 
>>> over the place when some change to some location was made, and it 
>>> sends notifications to every URI it has.
>>>
>>> Hmmm.  We might want to say that if the location was invalid 
>>> (regardless of whether validation was requested), and the LI sent 
>>> matches more than one location, the server MUST NOT save the URI, 
>>> and MUST send the error.  The text that says you may get a 
>>> notification even if it’s still valid could be expanded to cover 
>>> that case as an alternative to that.
>>>
>>> Brian
>>>
>>>> On Aug 23, 2021, at 6:12 PM, Randall Gellens 
>>>> <[e-mail] <mailto:[e-mail]>> 
>>>> wrote:
>>>>
>>>> In my suggested edits I changed this to add "may".
>>>>
>>>> --Randall
>>>>
>>>> On 23 Aug 2021, at 15:08, Caron, Guy wrote:
>>>>
>>>> Taken from section 3:
>>>>
>>>> The URI will be stored by the server against the location in the 
>>>> request for subsequent use with the notification function defined  
>>>> below.
>>>>
>>>> Guy
>>>>
>>>> De : Randall Gellens <[e-mail] 
>>>> <mailto:[e-mail]>>
>>>> Envoyé : 23 août 2021 17:51
>>>> À : Caron, Guy <[e-mail] <mailto:[e-mail]>>
>>>> Cc : Brian Rosen <[e-mail] <mailto:[e-mail]>>; 
>>>> [e-mail] <mailto:[e-mail]>
>>>> Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not 
>>>> always invalidated
>>>>
>>>> I don't know that that's true. My interpretation is that a LoST 
>>>> server might maintain a list of URIs but not associate each with 
>>>> specific location records, and when there is a change, it would 
>>>> then send a notification to each stored URI. The location that was 
>>>> used for the original validation query might not be impacted.
>>>>
>>>> --Randall
>>>>
>>>> On 23 Aug 2021, at 14:48, Caron, Guy wrote:
>>>>
>>>> I think these locations are impacted in one way or the other 
>>>> otherwise, the LoST server would not be able to determine that it 
>>>> should send notifications; they may just not become invalid in the 
>>>> LoST sense.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>> Guy
>>>>
>>>>
>>>>
>>>>
>>>> De : Randall Gellens <[e-mail] 
>>>> <mailto:[e-mail]>>
>>>> Envoyé : 23 août 2021 17:42
>>>> À : Caron, Guy <[e-mail] <mailto:[e-mail]>>
>>>> Cc : Brian Rosen <[e-mail] <mailto:[e-mail]>>; 
>>>> [e-mail] <mailto:[e-mail]>
>>>> Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not 
>>>> always invalidated
>>>>
>>>>
>>>> Using 'impacted' is not really better, because a location may or 
>>>> may not actually be impacted. If we go down the path of precise 
>>>> names we should use something such as 
>>>> 'locationPotentiallyInvalidated', which seems silly. I think the 
>>>> draft makes it clear (especially with my suggested edits) that a 
>>>> notified location is potentially invalidated.
>>>>
>>>> --Randall
>>>>
>>>> On 23 Aug 2021, at 14:24, Caron, Guy wrote:
>>>>
>>>> This new version introduces variability in whether a location is 
>>>> indeed invalidated or not by a change, which I agree with.
>>>>
>>>>
>>>> Given this, the names “locationInvalidated” and 
>>>> “invalidatedAsOf” seem misleading. Should “invalidated” be 
>>>> changed to something like “Impacted”?
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>> Guy
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/ecrit 
>>>> <https://www.ietf.org/mailman/listinfo/ecrit>
>>>> External Email: Please use caution when opening links and 
>>>> attachments / Courriel externe: Soyez prudent avec les liens et 
>>>> documents joints
>>>>
>>>> External Email: Please use caution when opening links and 
>>>> attachments / Courriel externe: Soyez prudent avec les liens et 
>>>> documents joints
>>>
>>