Subject: [Sip] Updated gruu mechanism spec

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 05 Dec 2003 17:20:31 -0500

Folks,

Based on discussions during the IETF 58 meeting, I've submitted a 
revision to the gruu mechanism document. Until it appears in the 
archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-sip-gruu-01.txt

The changes are as follows:

* clarified that the registrar needs to return the same gruu in 
registration refreshes, and this requires reliable storage. No 
requirement for returning the same gruu across registrations.

* clarified that the registrar should ignore any gruu parameter 
provided in the contact header fields of a registration

* mention that, it is still possible that a gruu changes in a 
registration, in the case where there is a race condition where the 
client thinks its refreshing, but the registration has just expired at 
the registrar. As such, recommend that a UA be prepared to deal with 
such a change.

* removed text about using this mechanism to replace dialog reuse

* added some more details on the encryption mechanism, such as 
recommended algorithm and key lengths. Also clearly state that this is 
just one way to do it, you can do it statefully if you want.

* proxies are prohibited from redirecting a request to a gruu, they 
have to proxy it. If they redirect, you'll ruin any nat traversal 
benefits associated with gruus.

* clarified that gruus don't provide sufficient privacy services, and 
added a reference to the privacy spec

* removed the notion of locally generated gruus. The text now says you 
need to use the registration mechanism in the draft to obtain a gruu. 
The result is the end of e2e signaling. It also mentions that a new 
specification is forthcoming which will address this limitation.

At this point, there are no known open issues. I would like to see if 
there is consensus to adopt this item as a work item of the sip 
working group. I do not believe we took such a poll during the 
meeting. Chairs - can you assist?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.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: "Christian Stredicke" <[email-masked]>
Date: Sun, 7 Dec 2003 23:12:51 +0800

Hi Jonathan,

I think we should add to the draft that the user agent which registers
using gruu and TCP must not close its TCP connection at least until the
registration expires (also the server must not close this connection,
but I think that’s clear). This would be an important clarification on
the TCP stuff which has recently been discussed.

If that desire should be programmable (to limit the number of concurrent
TCP connections on the server), then we must include a hint for the user
agent on how to behave. But surely the default behavior should be the
above.

Christian

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
> Jonathan Rosenberg
> Gesendet: Freitag, 5. Dezember 2003 23:21
> An: [email-masked]
> Betreff: [Sip] Updated gruu mechanism spec
> 
> Folks,
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 30 Dec 2003 10:26:26 -0800

I feel this should be adopted as a WG time with new milestone.

One curiosity question about the GRID parameter - it says that "MUST NOT
exceed 128 characters". I was wondering why this was added. I'm not really
against it but it struck me as inconsistent with all the the other things in
SIP which have no limit. 128 is also fairly low for doing all the state push
games that are done to avoid having cookies.

Cullen

PS. I wish some things did have limits (particularly the call-id which gets
passed into all kinds of data bases and billing system that do have real
limits.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 31 Dec 2003 15:55:57 -0500

Cullen Jennings wrote:

> exceed 128 characters". I was wondering why this was added.

Just as a general bound on size. This has been a real problem in the 
past (not defining size limits, and having implementations assume 
particular ones anyway).

> I'm not really

Thats probably true. I'll remove the limit.

-Jonathan R.