Document: draft-ietf-sip-consent-framework-03 Reviewer: Vijay K. Gurbani Review Date: 19 Dec 2007 IESG Telechat date: 20 Dec 2007 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Substantive comments are first, followed by nits. - Abstract and S1: The text says that SIP supports communications across many "media types, including real-time audio, video, text, instant messaging, and presence." However, real-time audio, video, text, IM&P are not "media types" as much as they are models of services (as defined in rfc4479.) Consider changing the text in the Abstract and S1 as follows: OLD: The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. NEW: The Session Initiation Protocol (SIP) supports communications for several services, including, real-time audio, video, text, instant messaging, and presence. I am aware of all the gyrations we have had on the SIMPLE mailing list about how to discover services over multiple devices, etc. However, I believe that we all do agree that real-time audio, video, IM&P, et al. are services. - S3, last paragraph at the end of Page 5: For the sake of completeness, I would suggest the following modification: OLD: Translation operations that result in more than one recipient URI are a source of amplification. Servers that do not perform translations, such as outbound proxy servers, do not cause amplification. NEW: Translation operations that result in more than one recipient URI are a source of amplification. Servers that do not perform translations, such as outbound proxy servers, do not cause amplification. On the other hand, servers that perform translations (inbound proxies authoritatively responsible for a SIP domain, for instance) may cause amplification if the user can be reached at multiple endpoints (thereby resulting in multiple recipient URIs.) - S4.1, third paragraph, last sentence: I think you need to be careful here because of the normative SHOULD in the preceding sentence -- is the example simply drawing a parallel to how a registrar works, or are you saying that a relay functionality can logically reside at a registrar? When you defined a Relay in S2, you did not include a registrar. - S4.2, second paragraph: s/If the answer is positive/If a 2xx-class response is issued to the MESSAGE request/ - S4.3: The first couple of paragraphs are trying to justify the existence of store-and-forward servers. I think the intent may be a bit clearer if the first two paragraphs are re-written as follows: When a MESSAGE request with a permission document arrives to the recipient URI to which it was sent by the relay, the receiving user can grant or deny the permission needed to perform the translation. However, the receiving user may not be available when the MESSAGE request arrives, or it may have expressed preferences to block all incoming requests for a certain time period. In such cases, a store-and-forward server can act as a substitute for the user and buffer the incoming requests, which are subsequently delivered to the user when he or she is available again. - S4.3: Paragraph three states that "There are several mechanisms to implement store-and-forward message services..." Is there an IETF RFC or I-D that can be referenced here? - Figure 4: Should message (3) be shown going from Relay to "B@example.com" instead of "B's Store & Fwd server"? The accompanying text in S5.3 seems to point this way, as does the discussion preceding Figure 4 (see S4.2, second paragraph.) If message (3) is indeed destined to "B@example.com", then this begs the next logical question: What if B is not online? Then the message has to bounce and be stored on B's S&F server. You discuss this aspect later on in S5.5, but I think it ought to be pointed out earlier. - S5.4, first paragraph: s/A permission document is the representation (e.g., encoded in XML) of a permission./A permission document is an XML-encoded representation of a permission that the owner of a URI wants to convey to a relay. - S5.4, last paragraph: I think this paragraph is confusing. With reference to Figure 4, who is the "Sender"? Is it A@example.com? But the text right above the paragraph says "Identity of the Sender: Any Sender". If so, who is to be authenticated? A@example.com or anyone that sends a message to the relay? - S5.6, first sentence: maybe it is better to say "A recipient gives a relay..." instead of "A client gives a relay..." The discussion in S5.4 centered around recipients granting permissions. To keep the flow of the document straight, I think it would be helpful to be consistent on terminology. - S5.6: while reading the second paragraph of the section, it seems like the recipient echoes the same permission document back to the relay. Is this always the case? What if the recipient wanted to modify the document and add/remove URIs to grant/deny permissions? Or change the identity of the sender? Is that possible? If so, it may be worth mentioning there. - S5.9: third paragraph begins with stating that "Relays implementing this framework and providing this type of ..." Here, what do the two instances of "this" refer to: the framework defined in the draft-ietf-sip-consent-framework-03 itself, or a different framework to handle URI-list services as described in the second paragraph, which I believe corresponds to the work in draft-ietf-sipping-uri-services-07? - Figure 6 is best put at the end of S5.9.1 because that section and the preceding section describe the behavior depicted in Figure 6. - In Figure 6, it appears as if the INVITE request consists of multiple R-URIs (which would be illegal as per the ABNF.) I think the intent here is probably to carry the set of URIs through the recipient-list disposition type specified in draft-ietf-sipping-uri-services-07. If so, maybe making this a bit more obvious in the example may not be a bad idea. - S5.10, third paragraph: I think the mention of sip-outbound muddies up the waters here. Certainly rfc3261 in and of itself does not depend on outbound like functionality to be implemented between a proxy/registrar and a UA. Why tie outbound to how a REGISTER transaction is supposed to work in rfc3261? - S5.10, third and fourth paragraphs: I think you need to make it more explicit that when using registrations as a mechanism to inject a recipient URI into a relay, the only way to do so is through 3rd-party registrations. Thus, we have to ensure that 3rd party registrations are valid through the return routability gyrations shown in Figure 7 (i.e., sending a MESSAGE to the URI in the Contact header of an incoming REGISTER, etc.) If you don't make explain the reason for this 3rd-party registration step in some detail, the nuances on why this is done is perhaps lost on the reader. - S5.10, the paragraph above Figure 7: s/at the registrar (4)./at the registrar (5)./ NITS: - In Figure 1, I would put vertical ellipses between the two arrows labeled "recipient URI". This is to visually denote that there are arbitrary many recipient URIs that may result from a translation. - S4.3: s/from day one./from the outset. - S4.4: the opening sentence was a bit hard to parse on a quick read. I had to re-read it for the sentence to make sense. I would suggest that it be re-written as follows: Permission documents generated by a relay include URIs that can be used by the recipient of the document to grant or deny the relay the permission described in the document. - S4.5, last paragraph: s/integrity- protected/integrity-protected/ - S5.3.1, the MESSAGE request shown as beginning on page 14 appears to be indented incorrectly. But this may have been intentional so as to pretty-display the permission document... - S5.9, third paragraph, second line: s/different ways as the relays/different ways from the relays/