Notes of conference call held on 11th September 2006 to review GRUU WGLC 
comments.

Participating:

Paul Kyzivat
Alan Hawrylyshen
Robert Sparks
Andrew Allen
Dale Worley
Cullen Jennings
Jonathan Rosenberg (Editor)
Dean Willis (Moderator)
Eric Rescorla
David Hancock
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

1) anonymity of gruus (note we started this on previous call but reached no conclusion 
-- I suspect list discussion has suggested that "yes, some change to the doc is needed" 
is the answer. Tracker #124A and others)
Noted: Come back to this one later in the call

2) When to apply GRUU - is it always? (Robert, tracker #4). 
Noted that JDR had followed up on list.
Clarified that the issue is when to use GRUU in Contact rather than when to create the 
GRUU.
Robert to send text, which will include 'Not the intent of this draft to preclude end-to-
end signalling".
One should always provide a contact with GRUU properties, either using registration-
minting or construction from configuration.

3) Lifetime of GRUU (Robert, tracker #11)
For anonymity to work, one can't require immortal GRUU. However cancellability 
requires state and Robert has requirement not to support state. 
Also need to discuss 404 vs 480 responses, such that the use of 404 responses does 
not imply state.
Do we think that GRUU must be perpetual? No, we need to specify mortality as an 
option.
Noted that we must NOT specify a mechanism that returns 480 to a GRUU that has 
never been minted.

4) Explicit mechanism for cancelling a GRUU? Do we need one?
Does removing the contact binding satisfy the requirement? Apparently not. It seems 
that the only solution is an automatic anonymizer service engaged by a privacy header. 
The contact minted by the anonymity server may need to be flagged as a GRUU.

5)  Lack of generality in grid/opaque design. Way for a more generic demux? (ekr, 
many tracker items)
This led to a discussion of of request-URI processing and rewrites on contact routing 
that would allow e2e parameter transparency. Need to ensure that the Request URI is 
not rewritten, and will need to be a property per contact.
Proposed that we delete GRID from GRUU, move it to a separate spec that fixes 
parameter passage in general. This will be a UA loose route technique and will be 
done without additional flags. Robert volunteers to help on this draft.

6) retargeting, forwarding services applied to gruu? Is this policy or protocol 
requirements?
Part of this is debate about whether GRUU is an alias for the Contact or for the AoR.
Noted that the GRUU doc needs to include a statement about intent.

7) GRUU as a header and a URI param (Robert, tracker #5)
Jonathan proposed a solution on email (rename to gr) that all seem happy with.

8) Statefulness required? (Robert, tracker #11 and others)
Already done, tied into cancellation and anonymity

9) in vs. out of dialog retargeting (Robert, tracker #12)
Robert finds asking a proxy to act differently in or out of dialog as added complexity. 
However, if we require this, the current text (test for route header) for "in or out" fails 
due to the possibility of preloaded routes. 
Do we really need to be able to detect this? It seems only service-treatment depends 
on it. Noted that 3261 is vague on handling a request with route headers.
Proposed that we can deal with this at the level of correctly describing proxy behavior 
for request with route headers, and not mandate different behavior on in/out of dialog.
The Route header processing may need further clarification generally.

10) Determining whether a request is mid-dialog or not, to apply service treatment 
(and other things) - how to do that? (Robert)
Mooted, see above.

11) Whether gruu needs to be explicitly flagged (This is a GRUU!) or not (Dean, 
tracker #6)
Reason is that there is such widespread violation of RFC 3261 requirements that 
Contact is globally routeable anyway that we need to do something.
Consensus: yes, it must be. No change to doc. If anywhere, this belongs in transfer 
spec.

12) Xavier's alternative proposal on To modification (Tracker #1)
Doing this makes GRUU less compatible with RFC 3261.
Consensus on "no" from this review team.

13) Home/edge proxy terminology - where to define, how to define
Suggested that this might belong in Outbound. Author will make a change to GRUU, 
referencing the outbound spec for the def. Cullen actioned to follow up in outbound.

deferred remaining points to next call.