I have not forgotten this. I have been asking around for other opinions. I still find it hard to believe that: sip:123;[EMAIL PROTECTED];user=dialstring
is preferable to: sip:[EMAIL PROTECTED];user=dialstring;phone-context=dial.example.com but if that is the way most people want it, it's not a big deal to change the text to reflect that. Brian -----Original Message----- From: Bob Penfield [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 26, 2006 12:34 PM To: Paul Kyzivat; Tom-PT Taylor Cc: [email protected]; [email protected]; Peterson, Jon Subject: Re: [Iptel] Gen-art review of draft-rosen-iptel-dialstring-03.txt I agree with Paul on the phone-context point. Just as user=phone hints/indicates that the userinfo is a phone number including its phone-context, dialstring should mean the same sort of construct. The phone-context is an attribute of the userinfo part of the URI. What would a phone-context SIP-URI parameter mean when there was no user parameter? or with a user=phone URI parameter? cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 [EMAIL PROTECTED] ----- Original Message ----- From: "Paul Kyzivat" <[EMAIL PROTECTED]> To: "Tom-PT Taylor" <[EMAIL PROTECTED]> Cc: <[email protected]>; <[email protected]>; "Peterson,Jon" <[EMAIL PROTECTED]> Sent: Wednesday, April 26, 2006 11:48 AM Subject: Re: [Iptel] Gen-art review of draft-rosen-iptel-dialstring-03.txt > There was other discussion of this back in March that, AFAIK, did not come > to a conclusion. Are that discussion and the Gen-ART review running in > parallel, or has the earlier discussion been forgotten? > > I had brought up two issues: > > - I propose that the phone-context parameter, reused from 3966, > should be used the way other parameters from 3966 are used > with a sip uri - in the user part. (If a phone-context parameter > is to be used as a sip URI parameter, then the syntax of the > sip URI will need to be updated to reflect this. But I don't > think that is the right thing to do.) > > - allowing use of # and * in dial strings. (Brian did agree to this.) > > Paul > > Tom-PT Taylor wrote: >> 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 >> >> >> >> >> >> >> _______________________________________________ >> Iptel mailing list >> [email protected] >> https://www1.ietf.org/mailman/listinfo/iptel >> > > _______________________________________________ > Iptel mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list [email protected] https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
