Subject: [Sip] review of draft-ietf-sip-gruu-10.txt

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 18 Aug 2006 14:13:20 +0200

Here are my review comments for draft-ietf-sip-gruu-10.txt (all nits):

section 2: 
- "contact: ... bound to an AOR or GRUU" => "... bound to an AOR and GRUU"
- "contact: ... the value of the Contact header field" => "a value" or "a Contact header field"
- "remote target: ... updated by target refresh requests" => add "or responses"
- "Contact header field: ... Depending on the semantics": isn't it simpler to say that in REGISTER requests and responses a Contact contains a contact, and in all other requests and responses it contains a remote target?

section 3:
"The AOR property: ... REGISTER request." => "REGISTER requests" (add 's')
"The alias property: ...is identical to another URI" => "is identical to the treatment of another URI" (is "treatment" well defined here?)
"anonymous property": perhaps better called the "anonymity property"?

The flow of this section is somewhat confusing: It first talks about properties a URI might have, then about three more properties that combine to form the GRUU property, and then adds a remark referring to "these properties" (page 5). Suggestion to have 1 list of all properties, then define the new property 'GRUU' which this specification adds

section 4.2 Conferencing:
"The URI in the Contact header field also has a callee capabilities [8] parameter which indicates that this URI is a conference URI." I assume this is referring to the "sip.isfocus" media feature tag, which "...indicates that the UA is a conference server" [12]. It is not a URI parameter but a header parameter

section 5:
"...will contain the "gruu" parameter in each Contact header field" => "will contain the "gruu" parameter in each corresponding Contact header field"
When the user has multiple registered UAs and some of those don't support GRUU, the REGISTER response would contain their Contacts without 'gruu' parameter

"RFC 3261 mandates that the Contact header field have the GRUU property, and this specification provides a reliable way for a UA to obtain one." => "...to fulfill that requirement" (UA obtaining a GRUU property makes no sense)

"...for a UA receiving the message to know whether the remote target is a GRUU or not.This can be known to a remote target through the presence of the "gruu" URI parameter." => " ..or not. It can learn this from the presence of the "gruu" URI parameter"

"...when that proxy receives a request sent to the GRUU, it can determine that the request is a GRUU by the presence of the "gruu" parameter" : although this section si not normative, I believe we said that a proxy should not depend only on the 'gruu' flag for this. Suggest to omit "by the presence of the 'gruu' parameter" here

"However, when the server maps the GRUU to the contact bound to it, the server will copy ..." => replace "the server"(2x) by "a proxy" and "it"

section 6:
"...the GRUU MUST exhibit the following properties:": add " The URI MUST NOT include the "grid" parameter" as a new bullet

section 7.1.1.1:

"...it is RECOMMENDED that a UA instance provide a different contact URI for each AOR": Do we need to specify how this should be done? Implementors might be tempted to use the 'grid' URI parameter for this, but that is not going to work. Distinct username parts would seem best? 
Actually, on second thought: is this really needed? a UAS can distinguish requests sent to different AORs by the URI in the To header; using that it can determine the right GRUU to use (ie typically it would maintain a mapping AoR domain -> GRUU )

"Specifically, if a contact contains an instance ID" -> capitalize "Contact"
"If a client does include a contact which contains a GRUU" -> idem

- Perhaps should also say that UA MUST NOT use "gruu" as a value in Proxy-Require (for completeness)
- can I get a GRUU for non-SIP Contacts? (e.g. "mailto:")

section 8.1.1:
- list of dialog-forming and target refresh requests and responses is incomplete. Should add "1xx responses to dialog-forming requests having a to-tag, UPDATE request + 2xx response"

- when a UA uses a GRUU e.g. in a PIDF document, can it convert 'sip' to 'sips' to have the other side use TLS until the proxy?

section 8.1.3: 
For out-of-dialog requests sent to a GRUU, the To header will contain the GRUU, including the 'grid' parameter (except for broken UACs that strip it). 
It seems that for GRUU purposes we could do without proxy copying of 'grid' and just rely on To? (though a URI parameter that survives rewriting can be useful for other applications, of course, for example between proxies)

section 8.2.1: (Request Targeting for Requests Outside of a Dialog)
"These requests are identified by their lack of a Route header field when received by the proxy": out-of-dialog requests could contain a Route header. It should say something like "request does not contain a Route header that the proxy recognises as one it inserted into a Record-Route header"

section 9 at the end: elements also need to strip any 'grid' URI parameter, if present, to obtain the AOR

Regards,

jeroen

_______________________________________________
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