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

From: "Andrew Allen" <[email-masked]>
Date: Tue, 22 Aug 2006 22:03:12 -0400

Another late review but here are my comments which I hope are not too
late to be considered:

Section 3

   A URI can have any combination of these properties.  It is the

   responsibility of the domain which mints the URI to determine what

   properties are conferred upon that URI.  This specification imposes

   requirements on a domain that mints a URI with the GRUU property.

Have we used the terminology "mints a URI" in SIP drafts before? If not
then I think non native English speakers may have some trouble with the
term "mints". Consider using "assigns", "allocates" or "manufactures"
instead.

Section 5

   A UA can obtain a GRUU by generating a normal REGISTER request, as

   specified in RFC 3261 [1].  

What is a "normal REGISTER request" or what is an abnormal REGISTER
request? Certainly a UA obtaining a GRUU using REGISTER will include
extensions in the REGISTER request. I think the word "normal" should be
deleted as it doesn't add anything.

Section 5

   When a proxy in the domain constructs the GRUU, it would set the

   value of the "opaque" URI parameter such that it includes the

   instance ID.  As such, 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, and then it can extract the AOR and instance

   ID, both of which are needed to process the request.

This text doesn't align well with the normative procedures in section 9.
Certainly it is possible that the "opaque" URI parameter could include
the instance ID but it isn't true that in all cases "it would set the
value of the "opaque" URI parameter such that it includes the instance
ID". Either change "would" to could or "can" or redraft this text to
more correctly indicate that the "opaque" URI parameter is set such that
it possible for a proxy in the domain to obtain the instance ID.

Section 7.1.2.1

   A REGISTER request might contain a Require header field; this

   indicates that the registration has to understand this extension in

   order to process the request.

This doesn't make sense. I think we need to replace "registration has to
understand" with "registrar has to understand"

Thus should read:

   A REGISTER request might contain a Require header field; this

   indicates that the registrar has to understand this extension in

   order to process the request.

Section 8.1.1

   If the UA instance has obtained multiple GRUUs for different AORs as

   a result of a registration, it SHOULD use one corresponding to the

   AOR used to send or receive the request.  For sending a request, this

   means that the GRUU corresponds to the AOR present in the From header

   field.  

And

   The GRUU placed into the Contact header field of the response SHOULD

   correspond to the AOR to which the request was targeted by the peer.

An issue that I think should be discussed is what happens when a UA uses
a TEL URI to send a request. What GRUU should be used in this case?
draft-ietf-sipping-gruu-reg-event provides a mechanism that could be
used by the domain to provide the UA with a GRUU for TEL URIs however
currently draft-ietf-sip-gruu doesn't mention use with TEL URIs at all
or provide any guidance on the allocation of GRUUs for use with TEL
URIs. Since a GRUU cannot be a TEL URI the property of being able to
obtain the identity used from the GRUU doesn't exist. 

Section 8.2.1

   Otherwise, handling of the GRUU proceeds as specified in RFC 3261

   Section 16.  For GRUUs, the abstract location service described in

   Section 16.5 is utilized, producing a set of zero or more contacts,

   each of which is associated with the same instance ID. 

Second sentence should contain RFC 3261 for the Section 16.5 reference
to avoid confusion whether this reference is within the present
document.

Andrew

 

 

 

 

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________
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