Draft: draft-ietf-sipping-cc-framework-07 Reviewer: Mahendran, AC [mahendra@qualcomm.com] Review Date: 2007-04-23 Review Deadline: 2007-04-13 Status: WGLC Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: ========= 1) Section 1 Text: "Primitives should be sufficiently robust that when they are combined they can be used to build lots of services." Replace with "Primitives should be sufficiently robust, so that when they are combined with each other, they can be used to build lots of services. " 2) Section 1, in the paragraph starting with "Primitives make full use of URIs....", replace two instances of "URLs" with "URIs". Note: there are other places in the document which use URL, where URI is more appropriate. So, please do a global search and replace of URLs with URIs. 3) Section 2, describes a bunch of key concepts (e.g., conversational space, signaling models, mixing etc). It is not clear how these "key concepts" are tied together. It'd be good to have a brief description indicating what section 2 trying to achieve. 4) Section 2.1, the second diagram has four participants (A, b, C, D), however, the entry above it only shows [A, B]. So, replace "[A, B]", with "[A, b, C, D]". 5) In section 2.1, text: "(essentially as a set of participants who believe they are all communicating among one another).", remove the brackets "()". 6) Section 2.2, the title "Comparison with Related Definitions" can be replaced to "Relationship between Conversation space, SIP Dialogs and SIP Sessions". >From the current title, it is not clear what is being compared to what! 7) It is not clear what sigaling models section 2.3 is trying to compare - is it 3pcc vs peer-to-peer? It would be better to compare "centralized" and "peer-to-peer" signaling models; 3pcc is one possible way to realize the centralized model. 8) In section 2.4.1.3, it'd be good to mention that media mixing is done by the end points. 9) In 2.4.2.2, replace two instances of "SIP" with "Signaling". 10) Section 2.7.1, text: "When a caller sends a request, it can optionally request Caller Preferences [21], by including the Accept-Contact and Reject-Contact headers that request certain handling by the proxy in the target domain." We should include "Request-Disposition" to the list of Caller Preferences header. 11) In section 2.7.2, text: "As we have shown, SIP URIs represent an ideal, flexible mechanism for describing and naming service resources, be they queues, conferences, voice dialogs, announcements, voicemail treatments, or phone features." "be they queues"? This phrase needs to be replaced. 12) Terminology issues: Section 1 uses the term "primitives", whereas section 3, uses the term "Call control actions". Are these the same? If yes, we should try to be consistent with the terminology. 13) Section 3.3.1 was confusing the first time I read it. It would be better to start out saying that the following section describes how call transfer can be achieved using 3pcc and REFER, and then describe the operations/procedures. Also, the sentence "Features enabled by this action..." can be reworded as: "The following features can be enabled by the "Transfer" action: " 14) Section 3.3.5 (Insert), we can add a reference to the "Join" RFC. 15) In section 3, in many of the examples, the messages needed to achieve a particular service are all shown in a single line (for example, in 3.3.6, to achieve split, the following messages are sent: REFER C Refer-To: conference-URI (new URI) REFER D Refer-To: conference-URI (new URI) BYE C BYE D). For better readability, it is advisable to split these into multiple lines. And one final comment: Section 2.1 defines a "Conversation space" model. According to Webster's dictionary, conversation means "(1) : ORAL exchange of sentiments, observations, opinions, or ideas". However, the framework is equally applicable to media sessions which are not audio/speech. So, may be, the model can be called "Communication Space" instead of "Conversation space".