I think your proposed changes are fine, and I will modify the text as you suggest.
Brian -----Original Message----- From: Tom-PT Taylor [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 26, 2006 8:36 AM To: [email protected]; [email protected]; [EMAIL PROTECTED]; Peterson, Jon Subject: Gen-art review of draft-rosen-iptel-dialstring-03.txt I am the assigned Gen-ART reviewer for draft-rosen-iptel-dialstring-03.txt. For background on Gen-ART, please see the FAQ at <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>. This draft is basically acceptable, but needs a few fixes. I have also identified a number of editorial issues. I suppose I'm going to get hell for not reviewing this draft in the two years it has been around, but better late than never. Substantive comments: ===================== 1. I believe the problem is mis-stated in the second paragraph of section 1. Ignoring the matter of RFC 2806-based implementations, the user part of a SIP URI with the "user=phone" parameter is, without ambiguity, a phone number. The real problem is that before the transformation occurs (and the "user=phone" parameter is added if applicable), entities beyond the originating point cannot distinguish between a dial string and an user part that happens to consist of the characters that can be present in a dial string. I suggest that the second paragraph be replaced by the following: "There is a problem here. The intermediary can apply its transformation only if it recognizes that the user part of the SIP URI is a dial string. However, there is currently no way to distinguish an user part consisting of a dial string from an user part that happens to be composed of characters that would appear in a dial string." It is also necessary to change the second-last requirement in section 3 as follows: Current text: " It MUST be possible to distinguish between a dialstring and a phone number." New text: " It MUST be possible to distinguish between a dialstring and an user part that happens to consist of the same characters." 2. The requirement in section 3 that a context be present is unmotivated. I suggest adding the following sentence at the end of the first paragraph of section 1: " The intermediary is able to perform this transform provided that it knows the context (i.e., dialling plan) within which the number was dialled." 3. In section 3, a dial string is defined to consist of a certain set of characters, but then the requirement to convey pause and "wait for call completion" is added. It would be cleaner to include the characters for the latter functions in the definition of dial string in the first place. I therefore suggest the following changes: -- move the requirement to represent pause and "wait for call completion" from its present position near the end of the section to follow the first sentence/requirement of the section. -- add the following bullet point to the list of characters in a dial string: <* Characters to express "pause" and "wait for call completion".> Editorial comments ================== General: "user part" and "dial string" (except as a parameter value), not "userpart" and "dialstring". Section 1, para 1, second sentence: "One enters ..." -> "The user enters ...". Section 1, para 1, third sentence: "The entered sequence, called a "dialstring", may ..." ^ ^^^ Section 1, para 3, first sentence: "post dial" -> "after the initial number has been dialled". Section 1, para 3, second sentence: "functions" -> "function". Section 1, para 3, end of third sentence: "as DTMF" -> "as a series of DTMF digits". Section 1, para 3: add this sentence at the end to make the point of the paragraph: "This is another case where the ability to indicate that a dialstring is being presented would be useful." Section 3, dial string character list, third bullet: "* The MF digits A-D" -> "* The DTMF digits A-D" Section 3, note on DTMF following the bullets: suggest this be indented (empty list item in XML2RFC) to show its informative status. Section 4 para 1, final sentence: "E represent *" -> "E represents *" <X represents call completion> -> <X represents "wait for call completion"> Section 4 para 2, final sentence: current: <change the URI to specify user=phone.> proposed: <change the URI parameter value from "user=dialstring" to "user=phone".> Section 4, voicemail example: to be consistent with the motivation in section 1, one would expect the dial string to be 4500X4123 rather than 4500P4123. Section 5, second para, second sentence: "This RFC would" -> "This RFC must". Section 5, third para, end: "[RFC3969]" -> "[RFC3966]" References, [RFC3969] repeats citation for [RFC3966] rather than giving the details for RFC 3969. Tom Taylor _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
