[sipcore] Rough notes from today's session

["Elwell, John" <[e-mail]>]

Status slides

Re-invite draft about to go into last call.
Security flows - issue of whether it waits for SHA-256. Cullen wants to get the present document done, and come back to SHA-256 later if needed. Needs to be cleared up with Security ADs.
Keep-alives - more review urged.
RFC3265bis - doesn't seem to be objections to changes proposed last time.
Cullen had a question on flows draft accompanying RFC4424bis, whether sub-addressing service should be separated out.


draft-ietf-sipcore-location-conveyance-03   - Jon Peterson
Keith: Believes the authors did not have WG consensus to make the changes that have been made to the draft. Jon explained that this was better than nothing, because they were too late to submit individual draft.

Main issue is multiple locations. The essence of the changes made is that now we have a single PIDF document, which can be composed to represent multiple locations if needed.

Keith: Asked whether his understanding was correct, that you have to go and fetch the PIDF document to get some of the information that previously in the header.

Martin Thompson: Concerned that people have already implemented what was previously in there. May be we just have to accept duplications between body and header. Could say that you should compose things into a single body, but keep the header information too.

Jon: In the past, the mechanism was optimised to having multiple locations in the request, which might not be such a common case.

Martin: Concerned more about some of the new drafts like rough-loc - intermediaries inserting is more a red-herring. Having just LbyR would probably work, but need to be pragmatic.

Brian Rosen: Doesn't like the mechanism, not because it doesn't work, but because intermediaries will still go ahead and do what they want. Mistake to make it so hard for intermediary to add location.

Jon: The trade-off is between this and the simple case.

Brian: In the 1% case, should allow intermediaries to insert.

Jon: The document does provide a mechanism for this, either adding LbyR or using 424 to get it resent with LbyR.

James Polk: All the old stuff has to come back in if you allow multiplexing in the header, as per old mechanism.

Arnot????: Described enterprise use case. Also pointed out that the draft has been his/3GPP dependency for a long time, and is holding up release of a frozen 3GPP release.

Keith: Even if there is only one location, the header needs to provide information for an entity to know whether it needs to go and look for the location.

Jon: Agree that this draft doesn't provide anything not supported in the earlier draft.

James Polk: We have lost the inserted-by indication. But this was only there to discriminate between multiple locations, and is not needed if there is only one location.

Martin: I read it that the intermediary because UAC if it wants to insert LbyR without using the 424 mechanism.

Adam: If intermediary inserts information, it does it by brute force, eliminating existing information. But before, it just pushed the problem down to the UAS to decide which is valid.

Brian: Reason the new mechanism won't work is that intermediary does not know anything about the accuracy of the information already there, and for liability reasons will not kick that out in favour of its own information.

Jon: Can still do so by changing the PIDF-LO.

Brian: The only change we need to make is to allow multiple values, which we can do without re-introducing all the old parameter.

Jon: Agree it is important to distinguish who added a location, device, service, user. But information is in body. Should either be in body or in header, not both. Easier to go with body.

Brian: Making the barrier too high. Happy to recommend composing in PIDF, but will not be able to enforce this as the only method.

Martin: Agree with Brian.

Some discussion about different bodies relating to different targets ????

Keith: Previously all information was in header to tell you wish location you might want to fetch first, which might be critical in an emergency call situation.

Jon: Don't understand how the information we could put in the header would help this.

Keith: ????

Martin: What we are looking at with multiple URIs is multiple schemes, or perhaps multiple targets.

Keith: I believe I am losing capabilities that I had in the previous draft.

Jon: Need to understand requirements in this area.

Hannes: Good that we shortened document, but guess that environments that Keith is looking at they will just put it in body. Andy while people implementing it would have been focusing on near-time cases, and have not done much with the header.

Compromise proposed that is to restore Geolocation header that has multiple URIs, even though we would not recommend it.

Brian: All the information you need is in body. Compromise seems reasonable.

Richard: Compromise seems good.

Martin: Just need to say that if you add to, you must ????

Brian: If multiple PIDFs, how do I know the difference? All in PIDF.

Keith: Question of how I trust the location.

Hannes: For emergency case, use what you have, ask if you want confirmation.

Jon: So I would go with this compromise, whereby if the bar is just too high to compose a new PIDF, you could convey multiple locations.

James: Asking about other header parameters.

Jon: No, we wouldn't re-introduce those parameters. Information is in the body.

Martin: ????

Jon: If you take the short cut of inserting multiple locations, you lose the semantics that would be in a composed PIDF-LO.

Keith: Not OK with the statement about being responsible - can only be responsible for information you insert, not responsible for the whole set of locations.

Jon: That is not the case here.

Jon: Need to articulate exactly what the responsibility situation is. Would be a SHOULD NOT for adding multiple location.

Jonathan Lennox: ????

Jon: Anyone unclear on what the compromise is. Nobody.

Hum: All in favour of going ahead with making the changes to the document that Jon has just proposed as compromise.

Chair: If Keith believes there is more that needs to be accomplished, need to bring use cases along.

Issue of 424 header insertion. Proposal that an entity that inserts a location must deal with any 424 response. No objection.

Content-Location issue: It seems the compromise above obviates the need to discuss this.

Issue of privacy text: Probably existing privacy text is inadequate.

Martin: Enough information elsewhere, and a short amount of text might be sufficient, referencing what exists.

Error codes issue: - Skipped

Geo-URI issue: Already implicitly allowed as a form of absolute-URI.

Richard: Main focus of earlier comment was in context of multiple locations, which is covered by compromise above.

Adam: Good idea to mention it if you want people to use it, else they will think it is not allowed.

James: ????

Richard: ????

James: What to do about "using protocol"?

Richard: Completely sufficient just to refer to existing RFC.

Martin: Present text we have about RFC 3693 doesn't relate too well to what we have in the document at moment. Needs rewrite.

Keith: Was some discussion in SIP way back about URIs.

Jon: In summary, we have path forward for revision of the document.


draft-ietf-sipcore-event-rate-control-03: Krisztian Kiss

Proposal to go ahead with what is described on slides for Event header field in 200 OK to NOTIFY. Document would be revised quite quickly.

Concerning other comments, will make changes.