Subject: [Sip] Is GRUU generated in the case of registration with instance-ID and reg-ID

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 11 Oct 2008 01:11:47 +0200

Hi Francoise,

So, how would the registrar know whether a GRUU is requested or not in
the case described by Georg? Based on whether the gruu option-tag is
present?

It would be good to clarify this in the outbound spec.

Regards,

Christer

>>I think you are correct.
>> 
>>It doesn't mean we couldn't re-use reg-id for other purposes however.

>Hello,
>
>Both Outbound and GRUU drafts make use of the instance-ID for different
purposes during SIP registration. In GRUU only the instance-ID is needed
to generate a GRUU. >For Outbound both, instance-ID and reg-ID are
needed.
>
>My question now is, whether a GRUU will be generated when a REGISTER is
received at the registrar, which indicates both reg-ID and instance-ID
in the Contact 
>header. Reading outbound, it seems like instance-ID + reg-ID are *only*
used for outbound purposes.
>
>Thanks a lot for your help.
>
>Best regards
>Georg
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 10 Oct 2008 19:49:32 -0500

I think that's in the GRUU spec.

________________________________

	From: Christer Holmberg [mailto:[email-masked]] 
	Sent: Friday, October 10, 2008 16:12
	To: [email-masked]
	Cc: Audet, Francois (SC100:3055); [email-masked]
	Subject: [Sip] Is GRUU generated in the case of registration with instance-ID and reg-ID

	Hi Francoise, 

	So, how would the registrar know whether a GRUU is requested or not in the case described by Georg? Based on whether the gruu option-tag is present?

	Regards, 

	Christer 

	>Hello, 
	> 
	>Both Outbound and GRUU drafts make use of the instance-ID for different purposes during SIP registration. In GRUU only the instance-ID is needed to generate a GRUU. >For Outbound both, instance-ID and reg-ID are needed.

	> 
	>My question now is, whether a GRUU will be generated when a REGISTER is received at the registrar, which indicates both reg-ID and instance-ID in the Contact 

	>header. Reading outbound, it seems like instance-ID + reg-ID are *only* used for outbound purposes. 
	>

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 11 Oct 2008 05:21:00 +0200

So, the following applies:

request                                        response
-------------------------------------------------------

instance-id AND Supported:gruu               = gruu
instance-id AND reg-id                       = outbound
instance-id AND reg-id AND Supported:gruu    = outbound AND gruu
instance-id                                  = n/a

Correct?

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Francois Audet [mailto:[email-masked]]
Lähetetty: la 11.10.2008 2:49
Vastaanottaja: Christer Holmberg; [email-masked]
Kopio: [email-masked]
Aihe: RE: [Sip] Is GRUU generated in the case of registration with instance-ID and reg-ID

	Hi Francoise, 

	Regards, 

	Christer

---

From: Michael Procter <[email-masked]>
Date: Sun, 12 Oct 2008 19:08:39 +0100

> So, the following applies:
GRUU is a little more subtle than that.  If a UA provides an instance-id
to a GRUU-supporting registrar, then the registrar will create a GRUU
for that UA, whether it indicates support or not.

If it indicates support ('Supported: gruu') then it will receive the
GRUU in the 200 response to the REGISTER.  If it doesn't indicate
support, then it won't receive the GRUU.  See section 5.2 of the GRUU
draft for more details.

Note that the GRUU is still created for non-GRUU UAs, and that the GRUU
can be discovered by other devices using (for example)
draft-ietf-sipping-gruu-reg-event.

Regards,

Michael

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 12 Oct 2008 20:33:44 +0200

Hi,

>for that UA, whether it indicates support or not.

Then the question is: if I only want to use outbound, is it always ok that the registrar creates a GRUU for me (no matter whether it returns it or not)?

>support, then it won't receive the GRUU.  See section 5.2 of the GRUU

Then the text in 5.1, about the Require header is a little confusing. It says that Require:gruu will NOT require the registrar to even generate a gruu - only that the registrar is required to support gruu.

OR, does the text refer to the case when the request ONLY contains Require:gruu, but no instance-id?

"A REGISTER request might contain a Require header field with the
"gruu" option tag; this indicates that the registrar has to
understand this extension in order to process the request.  It does
not require the registrar to create GRUUs, however."

>draft-ietf-sipping-gruu-reg-event.

Maybe it would be good to clarify, in the outbound spec, that a gruu will be generated if the registrar supports gruu. Because, at least in 3GPP there has been some confusion about that, and I believe such clarification would prevent future interop problems.

Regards,

Christer

---

From: Michael Procter <[email-masked]>
Date: Mon, 13 Oct 2008 08:43:15 +0100

> Then the question is: if I only want to use outbound, is it always ok that the registrar creates a GRUU for me (no matter whether it returns it or not)?

I raised much the same question last year (March/April time), and I
think the conclusion was that creating the GRUU doesn't cause problems
and should be considered a Good Thing.

> not require the registrar to create GRUUs, however."

I think this is the normal Require processing.  Putting 'Require: gruu'
in your REGISTER will ensure that it will only succeed on a GRUU-aware
registrar.  It doesn't control or enforce any particular GRUU-related
processing, only that the registrar understands GRUU.  This behaviour
(requiring understanding, not invoking) is common for many but not all
SIP options.

> Maybe it would be good to clarify, in the outbound spec, that a gruu will be generated if the registrar supports gruu. Because, at least in 3GPP there has been some confusion about that, and I beli…

I'm certainly in favour of reducing ambiguity, where it exists, but I'm
not sure outbound is the place to talk about GRUUs.  How did the
confusion arise?  The GRUU spec seems reasonably clear on this point.

Regards,

Michael

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Oct 2008 09:33:47 -0400

Its been a long time, and the details are starting to get fuzzy in my 
mind. But I'm quite sure Michael is right here. The first registration 
with an instance id causes the creation of a permanent gruu, and every 
registration with an instance id results in creation of a temp gruu. 
This is regardless of whether the registering UA indicates support for 
gruu. If it does, then it receives a copy of the gruu in the response.

	Thanks,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 13 Oct 2008 11:11:22 -0500

Just to make sure I understand, what does your "response column" mean?
Are you talking about the Require option-tag?

> -----Original Message-----
> Sent: Friday, October 10, 2008 20:21
> To: Audet, Francois (SC100:3055); [email-masked]
> Cc: [email-masked]
> Subject: VS: [Sip] Is GRUU generated in the case of 
> registration with instance-ID and reg-ID
> 
> 
> 	So, how would the registrar know whether a GRUU is 
> requested or not in the case described by Georg? Based on 
> whether the gruu option-tag is present?
> 
> 	>Both Outbound and GRUU drafts make use of the 
> instance-ID for different purposes during SIP registration. 
> In GRUU only the instance-ID is needed to generate a GRUU. 
> >For Outbound both, instance-ID and reg-ID are needed.
> 
> 	> 
> 	>My question now is, whether a GRUU will be generated 
> when a REGISTER is received at the registrar, which indicates 
> both reg-ID and instance-ID in the Contact 
> 
> 	>header. Reading outbound, it seems like instance-ID + 
> reg-ID are *only* used for outbound purposes. 
> 	>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 13 Oct 2008 19:50:51 +0200

Hi, 

>Are you talking about the Require option-tag?

No, I am talking about the Supported option-tag.

But, I think the reply from Michael clarified, but now DO have a question regarding the Require option-tag (see other mail).

Regards,

Christer

> > 	Subject: [Sip] Is GRUU generated in the case of 
> registration with 
> > instance-ID and reg-ID
> > 	
> > 	
> > 
> > 
> > 	Hi Francoise,
> > 
> requested or not 
> > in the case described by Georg? Based on whether the gruu 
> option-tag 
> > is present?
> > 
> > 	>Both Outbound and GRUU drafts make use of the instance-ID for 
> > different purposes during SIP registration.
> when a REGISTER 
> > is received at the registrar, which indicates both reg-ID and 
> > instance-ID in the Contact
> >

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 13 Oct 2008 21:01:57 +0200

Hi Michael, 
   
>>>GRUU is a little more subtle than that.  If a UA provides an 
>>>instance-id to a GRUU-supporting registrar, then the 
>>>registrar will create a GRUU for that UA, whether it indicates
support or not.
>>>     
>>
>>Then the question is: if I only want to use outbound, is it 
>>always ok that the registrar creates a GRUU for me (no matter 
>>whether it returns it or not)?
>>   
> 
>I raised much the same question last year (March/April time), 
>and I think the conclusion was that creating the GRUU doesn't 
>cause problems and should be considered a Good Thing.

I think it is confusing that the 200 OK does not contain the gruu.
Shouldn't the 200 OK contain all currently registered contacts?

When a contact has been registered for an AOR (the RFC3680 statemachine
for the AOR is in "active" state), meaning that the AOR is reachable.

So, what is the justification for generating a gruu, but not returning
it (after all, the gruu will be sent to the UA if it registers to the
regevent package, so...)??? 

>>Then the text in 5.1, about the Require header is a little confusing.
It says that Require:gruu will NOT require the 
>>registrar to even generate a gruu - only that the registrar is
required to support gruu.
>in your REGISTER will ensure that it will only succeed on a 
>GRUU-aware registrar.  It doesn't control or enforce any 
>particular GRUU-related processing, only that the registrar 
>understands GRUU.  This behaviour (requiring understanding, 
>ot invoking) is common for many but not all SIP options.

My question is still: if the REGISTER contains instance-id AND
Require:gruu, is a gruu generated?

On one side the presence of instance-id always creates a gruu, but on
the other side the text says that the precense of Require:gruu does NOT
mandate the creation of a gruu.

OR, does the text simply mean that Require:gruu on its own (ie no
instance-id) does not mandate the creation of a gruu?

>>Maybe it would be good to clarify, in the outbound spec, 
>>that a gruu will be generated if the registrar supports gruu. 
>>Because, at least in 3GPP there has been some confusion about 
>>that, and I believe such clarification would prevent future 
>>interop problems.
> 
>I'm certainly in favour of reducing ambiguity, where it 
>exists, but I'm not sure outbound is the place to talk about 
>GRUUs.
>
>I think that the outbound spec should clarify that the instance-id,
when used with outbound, will also create a gruu, 
>according to the rules in the gruu-spec.
>
>How did the confusion arise?  The GRUU spec seems reasonably clear on
this point.

I don't remember the exact details, but: 3GPP uses gruu, and 3GPP has
adopted outbound for the multiple registration feature (previously it
was defined only for NAT traveral), so the question came up when the
procedures for the multiple registration feature was discussed: will a
gruu also be generated?

It may be obvious to people on this list, and of course we could clarify
it in the 3GPP specifications. But, I think this would be a useful
generic clarification in the outbound spec.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 13 Oct 2008 21:05:34 +0200

Hi, 

>Its been a long time, and the details are starting to get fuzzy in my
mind.

One should not have to remember the details - they should be clear by
reading the specs :)

>But I'm quite sure Michael is right here. The first registration with
an instance id causes the 
>creation of a permanent gruu, and every registration with an instance
id results in creation of a temp gruu. 
>This is regardless of whether the registering UA indicates support for
gruu. If it does, then it receives a copy of the 
>gruu in the response.

Yes. The question was whether instance-id AND reg-id also create a gruu.
The answer seems to be yes, but I think it would be good to clarify that
somewhere.

So, either the outbound spec has a note saying that a gruu will always
be created.

...and/or, the gruu spec says that a gruu will always be created - even
when the instance-id is used as part of another feature (e.g. outbound).

Regards,

Christer

> registrar will 
> >>> create a GRUU for that UA, whether it indicates support or not.
> >>>     
> >> Then the question is: if I only want to use outbound, is 
> it always ok that the registrar creates a GRUU for me (no 
> matter whether it returns it or not)?
> >>   
> > 
> >> Then the text in 5.1, about the Require header is a little 
> confusing. It says that Require:gruu will NOT require the 
> registrar to even generate a gruu - only that the registrar 
> is required to support gruu.
> >>
> >> OR, does the text refer to the case when the request ONLY 
> contains Require:gruu, but no instance-id?
> >>
> GRUU-aware 
> > I'm certainly in favour of reducing ambiguity, where it exists, but 
> > I'm not sure outbound is the place to talk about GRUUs.  
> How did the 
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
>

---

From: Michael Procter <[email-masked]>
Date: Mon, 13 Oct 2008 20:39:22 +0100

Hi Christer,

> Shouldn't the 200 OK contain all currently registered contacts?

Yes, the 200 OK should contain all currently registered contacts, but a
GRUU isn't a registered contact.  When the UA indicates support, the
GRUUs are returned as header parameters to their associated contact, not
as separate contacts.

> regevent package, so...)??? 

Sending a header parameter to a UA that doesn't declare it supports it
seems to be inviting interop issues.  I suspect this is the reason,
although I wasn't involved with that decision so I can't say
categorically what the reason was.

> instance-id) does not mandate the creation of a gruu?

I think it is this last one.  'Require: gruu' has no special meaning to
a gruu-supporting registrar - it only prevents non-supporting registrars
from handling the request. 

A gruu-supporting registrar will follow section 5, which contains the
phrase:
"If there is no valid public GRUU, the registrar SHOULD construct a
public GRUU"

Assuming the UA includes a +sip.instance, and doesn't try to do anything
silly (register the AoR as a contact, register a gruu as a contact),
then you SHOULD get a GRUU made for you.

> generic clarification in the outbound spec.

Maybe someone else would like to address this point.  Personally, I am
ambivalent.

Regards,

Michael

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 13 Oct 2008 21:53:50 +0200

Hi, 

>>So, what is the justification for generating a gruu, but 
>>not returning it (after all, the gruu will be sent to the UA if it 
>>registers to the regevent package, so...)??? 
> 

Fair enough, but the UA is still going to get it if it subscribes to the
regevent package, isn't it?

>I think it is this last one.  'Require: gruu' has no special 
>meaning to a gruu-supporting registrar - it only prevents
non-supporting 
>registrars from handling the request.

That sounds reasonalble, but I think it should also be clarified.

Again, it may be clear to all of us now, but in order to avoid having
this same disucssion again in a couple of years....

public GRUU"
> 
>Assuming the UA includes a +sip.instance, and doesn't try to 
>do anything silly (register the AoR as a contact, register a gruu as a
contact),
>then you SHOULD get a GRUU made for you.

Does instance-id AND Require:gruu also RETURN the gruu?

Or, if I want the gruu returned, and I want to mandate the registrar to
support gruu, do I have to send:

Instance-id AND Supported:gruu AND Require:gruu

Whatever the answer to my question is - clarification would be
appretiated :)

Regards,

Christer

---

From: Michael Procter <[email-masked]>
Date: Mon, 13 Oct 2008 21:30:58 +0100

> regevent package, isn't it?

Yes, it is.

> Does instance-id AND Require:gruu also RETURN the gruu?

No. GRUU draft section 5.2 contains:
"If the REGISTER request contained a Supported header field that
included the "gruu" option..."
so the Supported header is needed (although you might get a pub-gruu if
you squint at the parenthetical 'and the client supports GRUUs' since
having a Require: gruu could be considered evidence of supporting gruus
- I don't think this follows the spirit of the draft though).

> Instance-id AND Supported:gruu AND Require:gruu

GRUU draft, section 4.1 (extract from last paragraph):

"If a UA wishes to guarantee that the REGISTER request is not processed
unless the domain supports and uses this extension, it MAY include a
Require header field in the request with a value that contains the
"gruu" option tag. This is in addition to the presence of the Supported
header field also containing the "gruu" option tag."

So it looks like you need all three: +sip.instance, Require:gruu and
Supported: gruu.

> Whatever the answer to my question is - clarification would be

I hope this helps!

Michael

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Oct 2008 18:54:09 -0400

> One should not have to remember the details - they should be clear by

Right. But I was being lazy.

> The answer seems to be yes, but I think it would be good to clarify that

Since reg-id isn't mentioned in gruu, its irrelevant to the gruu spec, 
just as any other parameters are.

> when the instance-id is used as part of another feature (e.g. outbound).

That would require it to be aware that it was part of another feature.
IMO That's an unreasonable assumption.

The spec says what it means.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Oct 2008 19:07:48 -0400

>> categorically what the reason was.

I also don't recall for certain what the reason was. I think perhaps 
initially it was thought that gruus would only been generated when 
requested. But that led to some logical inconsistencies around the 
permanent gruu when others might need to observe the gruu. So it was 
concluded that the presence of the gruu was coupled to the 
AOR/Contact/Instance-ID tuple. I can't remember the exact problem cases 
right now, though I think they did come from me. I can probably find 
them in my mail history if I look hard enough. But there was so much 
discussion on gruu it would take me a long time.

> regevent package, isn't it?

Yup. But ought to ignore any parts of the extension schema it doesn't 
understand.

> That sounds reasonalble, but I think it should also be clarified.

What are we clarifying? We know what the standard meaning of Require is. 
And we know that no additional meaning is provided. Why is more required?

> this same disucssion again in a couple of years....

If that is the point, the *maybe*. Given the state of the draft, it 
would probably have to be in Auth 48 if Jonathan wants to do it. Else it 
would be quite a pain.

> Instance-id AND Supported:gruu AND Require:gruu

I think the latter is correct. Require and Supported have different 
uses. As defined, Supported says "I am willing to have the GRUU returned 
to me, if it is available". My request still succeeds, but without 
getting the GRUU, if the registrar doesn't support gruu. "Require" says 
my request should fail if the registrar can't create the gruu.

This is all "SIP 101" stuff.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 14 Oct 2008 07:13:03 +0200

Hi, 

>>The answer seems to be yes, but I think it would be good to clarify 
>>that somewhere.
>

That is why I proposed it is clarified in the outbound spec :)

Regards,

Christer

---

From: <[email-masked]>
Date: Tue, 14 Oct 2008 08:53:44 +0300

Hi, 

>One should not have to remember the details - they should be clear by

I agree, however the specs often lack the rationale behind
the agreed design choices. So even if you see something has
specified in a certain way, in some cases you will have hard
time understanding why, unless you dig into the email archives.

>just as any other parameters are.

Right. Registrar compliant to the GRUU spec will create gruu
when it sees the Contact header field in the REGISTER message to
contain a "+sip.instance" header field parameter. The registrar
does not need to understand other parameters specified in Outbound
spec. I admit it is a bit confusing to use the same parameter in
two different specs that should be orthogonal, but it just happens
to be the specified behaviour.

>regevent package, so...)??? 

I also raised this question in march 2007 while reviewing GRUU spec
and received an answer from Paul Kyzivat, who had a point:

[email-masked] wrote:
> Hi Jonathan,
> 
> GRUU draft tells the registrar to create a public GRUU and a
> temporary GRUU whenever it receives a REGISTER request with
> "+sip.instance" Contact header parameter but only return
> them is the REGISTER request contains Supported: gruu.
> 
> Does this make any sense ? Why would the registrar have to
> create those GRUUs if it would not return them to the UA ?
> 
> The use case I am thinking is:
> 
> - A registrar which supports both GRUU and Outbound 
> - An UA which supports Outbound but not GRUU
> 
> Such an UA would send its Contact header with "+sip.instance"
> parameter but it would not include Supported: gruu in its
> REGISTER. Strictly speaking GRUU draft currently tells
> the registrar to create GRUUs but not to return them to 
> the UA.
> 
> I would assume GRUU draft needs a small fix to tell the
> registrar to create the GRUUs only if the REGISTER
> request contains "gruu" option tag in Supported header.
> 
> Do you agree or have I missed something ?

This is partially one of those questions like "does a tree that falls 
make any noise if nobody is listening?"

If in fact nobody will learn about this gruu then there is no need to 
create it. But that is all about the difference between the conceptual 
model and the implementation, so it doesn't need to be stated.

The problem arises when there are multiple observers of registration 
state. There are at least two ways this can happen:
- other UAs that register
- subscribers to the reg event package

After you register, if others register they will get your contact back 
in the response to their register request, along with their own. If they

support gruu, then they will will see the permanent gruu and latest temp

gruu for your contact.

Similarly, when you register, any subscribers to the reg event package 
will get a notify telling of the change in registration state, including

your contact and the gruus that were "assigned" to you.

Everything hangs together better this way. Still, if nobody is looking 
you don't have to assign these, as long as you do assign them when 
somebody does start looking.

	Paul
--

Perhaps this could have been worth mentioning in the GRUU spec.

>I think that the outbound spec should clarify that the 
>instance-id, when used with outbound, will also create 
>a gruu, according to the rules in the gruu-spec.

I understand the point that Outbound spec should actually NOT
talk about creation of gruus, as that is the task of GRUU spec.
However Outbound refers to GRUU spec twice, so what about 
modifying the note within section 6 as like this:

   A Contact header field value with an instance-id media feature tag
   but no reg-id header field parameter is valid (this combination can
   be used in the GRUU [I-D.ietf-sip-gruu] specification as creation
   of gruu is not dependent on the presence or absence of reg-id 
   parameter), but one with a reg-id but no instance-id is not.  

Regards,

Erkki

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 14 Oct 2008 08:17:08 +0200

Hi Erkki, 

mind.
reading the specs :)
>
>I agree, however the specs often lack the rationale behind the agreed
design choices. So even if you see something has specified in a certain 
>way, in some cases you will have hard time understanding why, unless
you dig into the email archives.

It is not about the rationale - but to understand the spec :)

>I also raised this question in march 2007 while reviewing GRUU spec and
received an answer from Paul Kyzivat, who had a point:
>
> GRUU draft tells the registrar to create a public GRUU and a temporary

> GRUU whenever it receives a REGISTER request with "+sip.instance" 
> Contact header parameter but only return them is the REGISTER request 
> contains Supported: gruu.
> 
> Does this make any sense ? Why would the registrar have to create 
> those GRUUs if it would not return them to the UA ?
> 
> parameter but it would not include Supported: gruu in its REGISTER. 
> Strictly speaking GRUU draft currently tells the registrar to create 
> GRUUs but not to return them to the UA.
> 
> I would assume GRUU draft needs a small fix to tell the registrar to 
> create the GRUUs only if the REGISTER request contains "gruu" option 
> tag in Supported header.
> 
>After you register, if others register they will get your contact back
in the response to their register request, along with their own. If 
>they support gruu, then they will will see the permanent gruu and
latest temp gruu for your contact.
>Similarly, when you register, any subscribers to the reg event package
will get a notify telling of the change in registration state, 
>including your contact and the gruus that were "assigned" to you.
>
>somebody does start looking.

If I don't support gruu, but I register to the regevent package, I WILL
hear the tree falling, because I will receive the gruu in the NOTIFY :)

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 14 Oct 2008 08:17:30 +0200

Hi, 

>>>Or, if I want the gruu returned, and I want to mandate the registrar
Supported: gruu.

I guess the text could say that "This is in addition to the presence of
the Supported header IF THE UA WANTS THE REGISTRAR TO RETURN THE GRUU." 

Because, the gruu itself will be created even without the Supported
header.

I am not sure that we before have defined a mechanism where an
option-tag may have to be present in BOTH the Require and Supported
header, so that is why I think the text needs to be really clear.

Thanks!

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Oct 2008 08:18:01 -0400

The reason outbound and gruu are using the same instance-id is that both 
uses share the same definition of the concept of a UA instance.

	Thanks,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Oct 2008 12:19:00 -0500

Can you propose actual text for a specific section. 

> Sent: Monday, October 13, 2008 22:13
> To: Paul Kyzivat
> Cc: Michael Procter; [email-masked]; Audet, Francois (SC100:3055)
> Subject: RE: [Sip] Is GRUU generated in the case of

---

From: Dean Willis <[email-masked]>
Date: Wed, 15 Oct 2008 00:33:46 -0500

> So, the following applies:

It seems like instance-id by itself could be useful for detecting
expired registrations from the same node, outside of gruu or outbound.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 15 Oct 2008 07:57:48 +0200

Hi,

The text would be something like:

"NOTE: If the registrar supports gruu [reference-to-gruu-spec], the
presence of the instance-id in the REGISTER request will also trigger
the registrar to generate a gruu for the user, as described in
[reference-to-gruu-spec]."

I will look for a place in the outbound draft where to put it, but it
really isn't more complicated than that. Just a simple clarification
note :)

Regards,

Christer

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: 14. lokakuuta 2008 20:19
To: Christer Holmberg; Paul Kyzivat
Cc: Michael Procter; [email-masked]
Subject: RE: [Sip] Is GRUU generated in the case of registration with
instance-ID and reg-ID

> Subject: RE: [Sip] Is GRUU generated in the case of registration with 
> instance-ID and reg-ID
> 
> 
> Hi,
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 15 Oct 2008 08:02:53 +0200

When SIP was born, it was all about the user, not the device...

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Wed, 15 Oct 2008 01:53:03 -0500

> When SIP was born, it was all about the user, not the device...

That's because we didn't have all MacBooks, iPhones, and Google Androids
back then. Instead, we had to encode our REGISTER messages on tiny slips
of paper attached to the legs of carrier pigeons.

Seriously, IIRC back in 1998 UUNET honcho John Sidgemore made a speech
where he claimed it would not be long before the average person in the
developed world would have or more five internet-connected devices. We
all laughed at the silly man. Now I have dozens of Internet-connected
devices, including cell phones, music players, laptops, desktops,
microservers, WiFi routers, printers, voice mail, SIP phones, and so on.

He was right, and we should have thought about the implications to SIP a
little more carefully.

---

From: <[email-masked]>
Date: Wed, 15 Oct 2008 12:08:15 +0300

Hi Francois,

Just in case you missed it, I repeat my proposal from
yesterday. The clarification could be added to the note 
within section 6 of Outbound like this:

Regards,

Erkki

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Francois Audet
>Sent: 14.October.2008 20:19
>Cc: [email-masked]
>Subject: Re: [Sip] Is GRUU generated in the case of 
>registration withinstance-ID and reg-ID
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Oct 2008 10:58:53 -0500

Agree. Using instance-id by itself has lots of usages. 

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Tuesday, October 14, 2008 22:34
> To: Christer Holmberg
> Cc: Audet, Francois (SC100:3055); [email-masked]
> It seems like instance-id by itself could be useful for 
> detecting expired registrations from the same node, outside 
> of gruu or outbound.
> 
> --
> Dean
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Oct 2008 11:01:49 -0500

I'm ok with this and unless there are complaints, I'll add it to the text. 

> Sent: Tuesday, October 14, 2008 22:58
> To: Audet, Francois (SC100:3055); Paul Kyzivat
> "NOTE: If the registrar supports gruu 
> [reference-to-gruu-spec], the presence of the instance-id in 
> the REGISTER request will also trigger the registrar to 
> generate a gruu for the user, as described in 
> I will look for a place in the outbound draft where to put 
> it, but it really isn't more complicated than that. Just a 
> simple clarification note :)
> 
> Regards,
> 
> Christer
> 
>  
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Oct 2008 11:02:13 -0500

I'm ok with this, and unless there are complaints, I'll add it to the text. 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, October 15, 2008 02:08
> To: Audet, Francois (SC100:3055); 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> >Subject: Re: [Sip] Is GRUU generated in the case of registration 
> >withinstance-ID and reg-ID
> >
> >> >>Yes. The question was whether instance-id AND reg-id 
> also create a
> >> gruu.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 15 Oct 2008 19:41:35 +0200

Hi,

>Agree. Using instance-id by itself has lots of usages.

Yes. The "n/a" in the table was only from a pure gruu- and outbound perspective.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Oct 2008 13:55:28 -0400

> I'm ok with this and unless there are complaints, I'll add it to the text. 

This will cause a two way dependency between gruu and outbound.
Maybe that is ok, since gruu has been stable for months (years?) and has 
been stalled awaiting the clearance of its dependency on outbound.

	Thanks,
	Paul

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 16 Oct 2008 14:05:35 +0200

It should not do because in my understanding this is an informative
reference, and we do not hold documents waiting for completion of
informative references.

In any case I guess we will get gruu and outbound published within days
of each other due to the reverse dependency.

Regards

Keith 

> Behalf Of Paul Kyzivat
> Sent: Wednesday, October 15, 2008 6:55 PM
> To: Francois Audet
> Cc: [email-masked]; Christer Holmberg
> Maybe that is ok, since gruu has been stable for months 
> (years?) and has been stalled awaiting the clearance of its 
> dependency on outbound.
> 
> 	Thanks,
> 	Paul
> 
> [reference-to-gruu-spec], the 
> it, but it 
> [email-masked] for questions on current sip