[martini] Rough notes

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

Participants: (Spencer has list)

Sole topic is gin (Adam).

Ticket #51
----------
Keith didn't like wording to first part of change - to be handled by email.
John suggested something along the lines of "To reject a request because it returns both parameters, the registrar MUST ..."
Adam clarified further in that you MUST not return a success code, and if this is the reason you are rejecting, then you MUST return 400.
Otherwise no comment.

Mailing list discussion on mandatory/optional status of public GRUUs
--------------------------------------------------------------------
Cullen is concerned about SHOULD, because unclear how things like transfer and message waiting lamp would work without it.
John explained that call transfer can still be accomplished by 3PCC means, which is the lowest common denominator if there is reluctance to accept a REFER request for security or charging reasons. He also stated that an SSP could perform mapping between local and global contact URIs, and does not necessarily need to use the public GRUU mechanism for assigning global URIs.
Discussion moved towards the need for more text stating the consequences of not supporting public GRUU, e.g., SP mapping to a globally routable URI.
Andrew was concerned about impact on remote party.
It was noted that there are UAs that don't support GRUU anyway.
John to propose text, with MUST/unless formulation (unless you have some other means of providing a globally routable contact URI).
Concern from Brian that we had consensus on list not to use MUST.
But this would be MUST/unless. In other words, there must be a globally routable address, but not necessarily obtained by the GRUU mechanism.
E911 callbacks were mentioned as another case for needing GRUU.
Brian disagrees. 
The chair asked that we proceed to generate the text proposal on the list and do a consensus call based on that, rather than now.

Ticket #57
----------
Consensus already obtained on list.

Ticket #56
----------
No comments

Ticket #61 (parts 1 and 2b)
---------------------------
Andrew asked how end UA discovers if temp-gruu has gone away.
Cullen: you would have to maintain a subscription to the reg event package.
(Various questions and clarifications around this).

Ticket #60
----------
Keith pointed out reference should be to 7.1 and 7.2.

Concerning Path, Cullen wanted to know why we mandated Path, and had pointed out this would bring in a SHOULD support for S/MIME (for delivering a copy of the original request to the registrar). Moreover, the "unless" part of the SHOULD, whilst it applies to IMS, would not apply in the general case, thereby making it effectively a MUST. Because nobody implements S/MIME, this means RFC 3227 is effectively broken. This doesn't actually impact the text of 7.4, but text earlier in the document was the target of the concern.
Hadriel said that we only mandate the inclusion of the path option tag in the Supported header.
Cullen was more concerned about whether registrar is required to support Path.
Adam: Registrar does have to support Path, and has been there since about 03. Apparently was put there to satisfy REQ-010 from RFC 5947.
Cullen: Let's move on - unclear how to deal with this.

Ticket #55 (+ ticket #61 part 2a)
---------------------------------
No comments

Ticket #59, issue 3
-------------------
Adam looking for feedback.
Paul concerned about the subscriber getting two pieces of information as a result of forking, and if you just take the first, it becomes a race condition which you get.
Much discussion, but came back to needing to update RFC 3680, as proposed in -07. No objection.

Ticket #59 , issue 1
--------------------
No comments.

Ticket #61, part 3
------------------
No comments.

Ticket #56
----------
No comments.

Summary
-------
John to propose text for 7.1.1, and Cullen to give further consideration as to what to do about Path. Cullen thinks we may have to concede we cannot meet REQ-010. Issues with Path are such that perhaps they should be addressed in a separate document. Perhaps we can say in the security considerations section that this makes the security situation with Path no worse than it already is.

When these issues have been dealt with, the document will be ready for publication request.

Concerning whether we need a meeting in Beijing, this depends. If there is nothing to discuss on gin, but gin is still not sufficiently through the approval process, the intent would be not to start work on the olive and vermouth drafts, in which case the WG may not need to meet.


John