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

["Caron, Guy" <[e-mail]>]

I’m not concerned about a client that willfully and knowingly asks for it.

This whole draft revolves around location validation. I’m not understanding the pushback here.

Guy

De : Randall Gellens <[e-mail]>
Envoyé : 23 août 2021 18:31
À : Caron, Guy <[e-mail]>
Cc : Brian Rosen <[e-mail]>; [e-mail]
Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation?


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]<mailto:[e-mail]>>
Envoyé : 23 août 2021 18:14
À : Caron, Guy <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[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]<mailto:[e-mail]>
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