Draft: draft-ietf-sipping-gruu-reg-event-03 Reviewer: Jonathan Rosenberg [jdrosen@cisco.com] Review Date: Monday 5/1/2006 2:15 PM Review Deadline: 4/7/2006 Status: post WGLC Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. [Note: since these comments were received after we requested publication, they will be incorporated post AD review or post IETF LC, based on feedback from the AD.] Comments: * Abstract needs to spell out acronyms (GRUU) and provide a bit more motivation. Also, abstracts cannot contain references as they are frequently quoted outside of the document itself. Suggest: RFC 3680 defines a Session Initiation Protocol (SIP) event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including its registered contact. However, the registered contact is frequently unreachable and thus not useful for watchers. The Globally Routable User Agent URI (GRUU) has been defined for SIP as a URI that is capable of reaching a particular contact, however this URI is not present in the format defined in RFC 3680. This extension defines an extension to the registration event package to include it. > 1. Introduction > > The addition of GRUU (Globally Routable Unique URI) support to the GRUU is Globally Routable User Agent URI. The first paragraph provides fairly weak explanation of the problem. Suggest: RFC 3680 defines a Session Initiation Protocol (SIP) event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including its registered contact. However, the registered contact is frequently unreachable from hosts outside of the domain of the user agent. It is commonly a private address, or even when public, direct access to it may be blocked by firewalls. The Globally Routable User Agent URI (GRUU) [3] has been defined as a URI that reaches a particular UA instance, but is reachable by any host on the Internet. The GRUU represents another piece of registration state. However, the GRUU is not included in the notifications provided by RFC 3860. For many applications of the registration event package, the GRUU is needed, and not the registered contact. > with the combination of the AOR and the Instance ID. When present, > the element MUST be be positioned as an instance of the > element within the element. given the differening meaning of the term 'instance' in the previous sentence, suggest: When present, the element MUST be positioned as a child of the element. Its also a good idea to clarify that it is possible for multiple registered contacts to have the same instance ID, and in that case each would have a element with the same value. Suggest: Note that it is possible for multiple registered contacts to share the same instance ID. In such a case, each element would have a child element, and the URI contained within those elements would be identical. Since a particular contact can not be associated with more than one instance IDs, a element will never have more than one child elements. You also never actually state that the content of the element is a single URI, equal to the assigned GRUU. Never assume anything as obvious. Suggest: The contact of the element is the GRUU that has is associated with the instance ID and AOR of the registered contact. > > sip:user@example.com > ;opaque=hha9s8d-999a Note that the most recent GRUU specification uses the ;gruu URI parameter. This parameter should be included here. > contained GRUU as follows: > > MESSAGE sip:user@example.com;opaque=hha9s8d-999a SIP/2.0 add GRUU URI param > MESSAGE sip:user@example.com;opaque=hha9s8d-999a SIP/2.0 > To: > From: "SIPland Notifier" > Content-Type: text/plain > Content-Length: ... > > Welcome to SIPland! > Blah, blah, blah. From tag is missing. Header fields that are included should be correct. Also, note that per draft-ietf-sip-guidelines, if you are using ... for Content-Length you MUST call out that fact in your description. I would also suggest you include all required headers for the message. Quoting draft-ietf-sip-guidelines: > For an example of how to construct a good examples section, see the > message flows and message formatting defined in the Basic Call Flows > specification [21]. Note that complete messages SHOULD be used. Be > careful to include tags, Via header fields (with the branch ID > cookie), Max-Forwards, Content-Lengths, Record-Route, and Route > header fields. Example INVITE messages MAY omit session > descriptions, and Content-Length values MAY be set to "..." to > indicate that the value is not provided. However, the specification > MUST explicitly call out the meaning of the "..." and explicitly > indicate that session descriptions were not included. suggest that this text: > using the same contact. But each of those implicitly registered AORs > will have had a unique GRUU assigned, and there is no way defined to > report that assignment in the response. instead say: using the same contact. Each of those implicitly registered AORs will have a unique GRUU assigned. The REGISTER response will not include those GRUU; it will only include the GRUU for the AOR and instance ID explicitly included in the registration. > ;+sip.instance="" > ;gruu="sip:user_aor_1@example.net;opaque=hha9s8d-999a" need gruu URI param > Accept: application/reginfo+xml > Contact: gruu URI param GRUU URI param needed in the example document as well. > A GRUU document is an XML document that MUST be well-formed and > SHOULD be valid. GRUU documents MUST be based on XML 1.0 and MUST be > encoded using UTF-8. This specification makes use of XML namespaces > for identifying GRUU documents. The namespace URI for elements > defined for this purpose is a URN, using the namespace identifier > 'ietf'. This URN is: > urn:ietf:params:xml:ns:gruuinfo This spec is not defining a GRUU document at all. Indeed, guidelines on well-formedness and validity are already defined in RFC 3680. This document needs to instead simply declare the schema thusly: The element is defined within a new XML namespace URI. This namespace is "urn:ietf:params:xml:ns:gruuinfo". The schema for the element is: > BEGIN > Typcailly schema definitions in our specs have not been wrapped in BEGIN/END. > Security Considerations > > Security considerations for the registration event package is > discussed in RFC 3680 [2], and those considerations apply here. > > The addition of GRUU information does not impact security negatively > because the GRUU is less sensitive than the contact URI itself. Hmm. Thats debatable actually. One might argue that, since the contact was never really reachable, it was not possible before to obtain a unique handle by which I could reach an instance. But now, I can. However, since the GRUU gets routed through the home proxy first, features such as inbound screening and all can still be applied, so its OK. Might want to discuss this.