Draft: draft-ietf-sip-consent-framework-00.txt Reviewer: Mary Barnes [mary.barnes@nortel.com] Review Date: 17 October 2006 Review Deadline: 17 October 2006 Status: WGLC Summary: This draft is on the right track but has an issue and nits, described in the review. Issues: ------- - Section 4.3: I share the concern that Ben raised in his review with regards to this framework not making any recommendations about (or defining) a store-and-forward mechanism. The off-line user issue is real and it would seem to be a large impediment to deployment of this functionality if there is not a recommendation for a must implement mechanism. I don't expect this document to define the functionality since it is more general, but it does seem a requisite for this draft. Nits: ------ - General: the term "Translation Logic" is used almost interchangeably with "Translation Operation", although only the latter term is defined in section 2. It would make this document a bit easier to follow, if a single term was used, provided they do mean the same thing. Also, there is sometimes an "s" added to the use of the word "logic" - this likely is incorrect and should be changed if that term remains in the document. -Section 3, 1st paragraph following Figure 1: the wording is a bit awkward and reads as if it's redundant, although it's not. Propose rewording to something like the following: OLD: Thus, an essential aspect of a relay is that of translation. When a relay receives a request, it translates, following its translation logic, the Request-URI into one or more additional URIs. That is, the relay can create outgoing requests to one or more additional URIs. The translation operation is what creates the consent problem. NEW: Thus, an essential aspect of a relay is that of translation. When a relay receives a request, it translates the Request-URI into one or more additional URIs. Through this translation operation, the relay can create outgoing requests to one or more additional URIs, thus creating the consent problem. - Section 5.3, 5th paragraph, last sentence: OLD: The MESSAGE request also carry ... NEW: The MESSAGE request also carries ... - Section 5.9, 3rd paragraph, 1st sentence: OLD: ... this type of URI-list services behave in a slight different way... NEW: ... this type of URI-list services behave in a slightly different way...