Re: Is GRUU generated in the case of registration with instance-ID and reg-ID

Christer Holmberg wrote:
> 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...)??? 
>> 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.

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.

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

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

>>> 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?
>>>    
>> 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.

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?

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

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.

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

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

> Whatever the answer to my question is - clarification would be
> appretiated :)
> 
> Regards,
> 
> Christer
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email protected] for questions on current sip
> Use [email protected] for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip