Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation?

[Randall Gellens <[e-mail]>]

If a client wants to get notified that a location may have become 
invalidated, why do we care why or what type of client it is?

--Randall

On 23 Aug 2021, at 15:26, Caron, Guy wrote:

> I understand and what I’m suggesting is to be clear about what LoST 
> clients are expected to do. We do not want a leasy implementation 
> sending <plannedChange> across the board, don’t we? I think it is 
> easy and cheep to fix in the draft rather to try to fix 
> implementations later.
>
> Guy
>
> De : Brian Rosen <[e-mail]>
> Envoyé : 23 août 2021 18:14
> À : Caron, Guy <[e-mail]>
> Cc : [e-mail]
> Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to 
> validateLocation?
>
> Sure, PSAPs could be a LoST client for example.  A routing proxy can 
> be a LoST client.  But they wouldn’t ask to store the URI.  You have 
> to ask for it to get the notification.
>
> Brian
>
>
> On Aug 23, 2021, at 6:10 PM, Caron, Guy 
> <[e-mail]<mailto:[e-mail]>> wrote:
>
> You miss my point. The LoST client may not be a LIS. If we make it 
> explicit that only LISes are LoST clients in the context of this 
> draft, I may not have as strong objections.
>
> Guy
>
> De : Brian Rosen <[e-mail]<mailto:[e-mail]>>
> Envoyé : 23 août 2021 18:06
> À : Caron, Guy <[e-mail]<mailto:[e-mail]>>
> Cc : [e-mail]<mailto:[e-mail]>
> Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to 
> validateLocation?
>
> Only if it asked for it, per location.  It asked for it, it got it.
>
> It has NOTHING to do with actual calls.  It’s just an alternative to 
> periodic revalidation for records in the LIS.
>
> A more interesting issue is what does a LIS do when it deletes a 
> record for which a URI is stored in the server.  Probably it marks 
> that URI is OBE. Another possibility is that it stores a new URI that 
> is a catch-all “ignore me”
>
> Hmmm.  I wonder if we should have an explicit delete.  Null URI = 
> delete.
>
> Brian
>
>
>
>
> On Aug 23, 2021, at 6:01 PM, Caron, Guy 
> <[e-mail]<mailto:[e-mail]>> wrote:
>
> A LoST client that sends routing requests to the server would receive, 
> way after calls have been delivered, a notification with a 
> <locationInvalid> body. What would it do with this?
>
> Makes no sense to me.
>
> Guy
>
> De : Brian Rosen <[e-mail]<mailto:[e-mail]>>
> Envoyé : 23 août 2021 17:55
> À : Caron, Guy <[e-mail]<mailto:[e-mail]>>
> Cc : [e-mail]<mailto:[e-mail]>
> Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to 
> validateLocation?
>
> I don’t understand the reasoning on “creating havoc”.  I don’t 
> know why a client would ever do it, but it “works” in that the 
> server doesn’t have to validate to save the URI.  If I client sends 
> the URI and doesn’t validate, it’s weird, but not wrong.
>
> We can decide to prohibit it.  But we don’t really have a 
> justification.
>
> Brian
>
>
>
>
> On Aug 23, 2021, at 5:44 PM, Caron, Guy 
> <[e-mail]<mailto:[e-mail]>> wrote:
>
> I agree that accommodating this comment would require deeper XML 
> changes.
>
> If we do not want to go there, I think the draft should be clear that 
> there is no usecase for sending <plannedChange> outside of a location 
> validation request and as such, should normatively recommend not doing 
> so.
>
> I do not agree that a LoST server receiving <plannedChange> outside of 
> a location validation request would retain the URI and send 
> notification if the record changed afterward. I think this would 
> create havoc on the client’ side.
>
> Thanks,
>
> Guy
>
> De : Brian Rosen <[e-mail]<mailto:[e-mail]>>
> Envoyé : 23 août 2021 17:22
> À : Caron, Guy <[e-mail]<mailto:[e-mail]>>
> Cc : [e-mail]<mailto:[e-mail]>
> Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to 
> validateLocation?
>
> validateLocation is an attribute, not an element, so I can’t extend 
> it.
>
> There isn’t an actual requirement to tie plannedChange to 
> validateLocation.  It may not make a lot of sense, but if you did it, 
> the LoST server would not return validation data, would retain the URI 
> and would send the notification if the record changed.  Note my text 
> that the LoST server doesn’t store the LI - the notification is 
> “something changed” not “what you sent is guaranteed to be 
> invalid” or even “one or more of the elements you sent changed".  
> I thought about changing the name of the notification, but I didn’t 
> do that.  The practical use case remains the same.
>
> Brian
>
>
>
>
>
> On Aug 23, 2021, at 5:07 PM, Caron, Guy 
> <[e-mail]<mailto:[e-mail]>> wrote:
>
> Not all LoST server implementations perform location validations. When 
> location validation is requested by the client, it adds the 
> “validateLocation” attribute to the <findService> element.
>
> So the question is: Should “plannedChange” be bound to 
> “validateLocation”?
>
> If you believe not, what would be the expected behaviour of a LoST 
> server receiving a <plannedChange> element outside of a validation 
> request?
>
> Thanks,
>
> Guy
>
> ________________________________
> 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
>
> ________________________________
> 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


> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit