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-v2.htm 

or

https://www.softarmor.com/sipwg/reviews/gruu/gruu-10-comments-v2.doc

Agenda discussion on what to discuss in what order. Settled on the following list:

*	Its too complicated (Dean, Ekr)
	>	remove properties discussion?
	>	remove figure 3?
	>	remove some use cases?
	>	rewrite overview?
>	total flush, rewrite, and kill the editor
*	do we discuss UA treatment of a contact if it doesnt have gruu flag (Paul)
*	do we need more clarification on lifetime of gruus - gruus not assigned by 
registration
*	Lack of generality in grid/opaque design. Way for a more generic demux? (ekr)
*	retargeting, forwarding services applied to gruu? Is this policy or protocol 
requirements? 
*	All of Robert's issue mails:
	>	GRUU as a header and a URI param
	>	statefulness required?
	>	in vs. out of dialog retargeting
*	When to apply GRUU - is at always? Roberts comment.
*	Determining whether a request is mid-dialog or not, to apply service treatment 
(and other things) - how to do that? (Robert)
*	Deans comments on whether gruu needs to be explicitly flagged or not
*	Xavier's alternative proposal on To modification home/edge proxy terminolgy - 
where to define, how to define
*	bit about outbound proxies and what GRUU to use - comments that this is 
confusing
*	applicability of record-routing languages in basic trapezoid case
*	anonymity of gruus
*	Altenative gruu construction algorithm from ekr
*	SIP/SIPS text - should we say anything about SIPS? COnsolidate SIPS processing?
*	tel URI handling (Andrew)
*	GRUU/AOR URI equivalence - an issue? (Dale)
*	Escaping allowed in GRUU contact header param? (Dale)
*	do we need client generated insteance ID (Aki)

Its too complicated (Dean, Ekr) - Comment #008 and others:
Ekr regarded his comment as primarily editorial, however Dean says it is technically 
too complex. Ekr indicated that it was difficult to tell normative from informative. 
Agreed that we need to extract the explanatory information into a later part. Restate 
normative part as differences from RFC 3261 and do not restate RFC 3261. The 
primary idea of GRUU is simple but it is the secondary issues that make it more 
complex - need to get primary idea across to the audience as quickly as possible.
There was consensus on the need for reorganisation, with the emphasis on 
reorganisation rather than rewriting. Specifically: Figure 3: new simpler figure plus 
text. Use cases: REFER use case in introduction and move other use cases to an 
additional material area. Rewrite and simplify overview: Ekr agreed to provide the 
basis for this.

Anonymity: Cullen comment
Currently can always find the AoR. Lifetimes are infinite - why? Justification is for 
debugging and callback. This branches into the lifetime discussion.
Possible enhancements to provide flag in register which indicates please mint new 
GRUU - however the old one will remain valid. Dean says this is the start of his 
technically too complicated argument - GRUU should be an ephemeral anonymous 
identifier. 
Agreed to take the open issue to the list for discussion and resolution. Jonathan to 
draft the issue statement to the list.

Agreed we need another call. Keith Drage to arrange.