Notes of conference call held on 27th September 2006 to review GRUU WGLC comments. Participating: Paul Kyzivat Robert Sparks Andrew Allen Dale Worley Jonathan Rosenberg (Editor) Dean Willis (Moderator) Eric Rescorla Keith Drage (Scribe) Review comment status as at this meeting: https://www.softarmor.com/sipwg/reviews/gruu/gruu-10-comments-v3.htm or https://www.softarmor.com/sipwg/reviews/gruu/gruu-10-comments-v3.doc The following issues were addressed: 14) Bit about outbound proxies and what GRUU to use - comments that this is confusing. This was not a major issue, rather a need to phrase the requirements better. The list would be asked to come up with better text. 15) applicability of record-routing languages in basic trapezoid case (Cullen, tracker #112A) There are two cases here, the triangular and the trapezoid. Is there a way to turn off the record-routing in the trapezoid case. It was agreed to pull text on this issue into a standalone appendix on network design, which means that the normative text will remain very simple. 16) Alternative gruu construction algorithm from ekr (Tracker #124) EKR has already sent text to Jonathan which will be adopted. 17) SIP/SIPS text - should we say anything about SIPS? Consolidate SIPS processing? (ekr and others, tracker #49) Jonathan suggested punting text about SIPS and GRUU to a future document that would fix SIPS generally, rather than including something in GRUU that would have to change anyway. We need to consult with the Security area to see if this is OK. 18) tel URI handling (Andrew, tracker #91) Identified that RFC 3261 specifies that the address of record has to be a SIP URI. In normal use, the tel URI is an alias for the SIP URI that is the address of record. It was regarded as reasonable to add a sentence that states this, although it should be stated in terms that can be applied to all URI types and e.g. sos URN, rather than being specific to the tel URI. 19) GRUU/AOR URI equivalence - an issue? (Dale tracker #41, Francois tracker #76) Dale attempted to clarify his comment, which was that the equivalence matching rules in RFC 3261 do not apply in this case. For example when the opaque parameter is stripped then we still need to match if it has the same set of other parameters. It was agreed that we need a new URI comparison rule that is not the RFC 3261 rule in this case. 20) Escaping allowed in GRUU contact header param? (Dale, tracker #116) It was proposed that the GRUU parameter takes a quoted string and the associated text says that it is a URI. Dale would send suggested text and this issue was agreed to be resolved. 21) Do we need client generated instance ID (Aki, tracker #7) This was identified as an issue where some mechanisms already exist in ETAGS that attempt to do some of what is performed in GRUU. However the review team considered that the problems are sufficiently different to merit different solutions., e.g. softstate or not. It was considered that the proposal was insufficiently motivated to agree any change to the current mechanism. 22) Related to whether GRUU is explicit: What do UACs do differently (if anything) if a contact is a GRUU? (ekr, Dean tracker #6, others) Discussed already in previous calls on other issues. 23) Do we need more clarification on the lifetime of GRUUs?This keep coming up in non-registration-bound GRUU usages, like gateways. Can you delete a GRUU? (Robert, tracker #75) Dealt with on anonymity issue. There is one additional sublety in that we need to emphasise that a request for a new (regular) GRUU will quite likely give the same one as already in use. 24) Is the GRID functionality of UA-generated URI context something that is more generally useful than just with GRUU? (ekr) Dealt with on anonymity issue. 25) Is the GRID functionality of letting a contacted UA know that it was reached via a GRUU both needful and best done with GRID, or would another mechanism be more appropriate? (ekr) Dealt with on anonymity issue. Additionally the following two items were discussed: A) As agreed on the call last week, the gruu URI parameter will be renamed "gr". Jonathan had put a mail to the SIP WG list the previous night indicating this. B) Anonymity. It was identified that neither Cullen or Jeroen were on the call, and these were key stakeholders in this discussion. It was agreed that within the bounds of the current document, there was no need for a level of privacy that was greater than that already provided by RFC 3261. This does not preclude other documents in the future providing a mechanism for a greater level of privacy. The proposal is that on registration, two GRUUs will come back, the regular GRUU and the pseudononymous GRUU. In general UEs will need both, depending on the application they are trying to support. A related question, which impacts SIPPING, was as to whether both GRUUs need to be revealed in the reg event package. It was agreed that conveyance of both would need to be supported, but that we would need to look at the text for authorization policy on the pseudononymous GRUU. It was agreed that informative text was needed to indicate that the UE provides any recovery if the regular GRUU is mistakenly revealed, i.e. by blocking calls made to that GRUU. EKR agreed to produce text to make sure that the GRUU is secure and disctinct when it is minted at different times. The above was all agreed amongst the participants on the call. It was understood that there may well be people on the list who do not agree with the above and consensus will be determined on the list.