Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier
RFC 4967
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2020-01-21
|
05 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
|
2015-10-14
|
05 | (System) | Notify list changed from br@brianrosen.net to (None) |
|
2012-08-22
|
05 | (System) | post-migration administrative database adjustment to the No Objection position for Magnus Westerlund |
|
2007-07-31
|
05 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2007-07-31
|
05 | Amy Vezza | [Note]: 'RFC 4967' added by Amy Vezza |
|
2007-07-27
|
05 | (System) | RFC published |
|
2007-05-27
|
05 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2007-05-24
|
05 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
|
2007-05-06
|
05 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2007-05-03
|
05 | (System) | IANA Action state changed to In Progress from Waiting on ADs |
|
2007-05-01
|
05 | (System) | IANA Action state changed to Waiting on ADs from In Progress |
|
2007-04-19
|
05 | (System) | IANA Action state changed to In Progress |
|
2007-04-17
|
05 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2007-04-16
|
05 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2007-04-16
|
05 | Amy Vezza | IESG has approved the document |
|
2007-04-16
|
05 | Amy Vezza | Closed "Approve" ballot |
|
2007-04-16
|
05 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
|
2007-03-02
|
05 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2007-03-02
|
05 | (System) | New version available: draft-rosen-iptel-dialstring-05.txt |
|
2007-03-02
|
05 | Jon Peterson | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Jon Peterson |
|
2006-06-28
|
05 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund |
|
2006-06-27
|
05 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2006-06-27
|
04 | (System) | New version available: draft-rosen-iptel-dialstring-04.txt |
|
2006-04-28
|
05 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
|
2006-04-28
|
05 | (System) | Removed from agenda for telechat - 2006-04-27 |
|
2006-04-27
|
05 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Ross Callon by IESG Secretary |
|
2006-04-27
|
05 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
|
2006-04-27
|
05 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley |
|
2006-04-27
|
05 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by Jari Arkko |
|
2006-04-27
|
05 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
|
2006-04-26
|
05 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to Yes from Undefined by Cullen Jennings |
|
2006-04-26
|
05 | Cullen Jennings | [Ballot comment] Small problem in that 3969 reference looks wrong and 3rd para in section 5 refers to 3969 instead of 3966. |
|
2006-04-26
|
05 | Cullen Jennings | [Ballot Position Update] New position, Undefined, has been recorded for Cullen Jennings by Cullen Jennings |
|
2006-04-26
|
05 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie |
|
2006-04-26
|
05 | Lisa Dusseault | [Ballot comment] Is the length of a pause defined anywhere? |
|
2006-04-26
|
05 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded for Lisa Dusseault by Lisa Dusseault |
|
2006-04-26
|
05 | Brian Carpenter | [Ballot comment] I agree with Lars that the security section is weak. Isn't there a reference for this in the IPTEL document set? And, why … [Ballot comment] I agree with Lars that the security section is weak. Isn't there a reference for this in the IPTEL document set? And, why is this document a direct submission rather than an IPTEL WG document? Gen-ART review from Tom Taylor. Brian Rosen agrees with the proposed clarifications: 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. |
|
2006-04-26
|
05 | Brian Carpenter | [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Undefined by Brian Carpenter |
|
2006-04-26
|
05 | Brian Carpenter | [Ballot comment] I agree with Lars that the security section is weak. Isn't there a reference for this in the IPTEL document set? And, why … [Ballot comment] I agree with Lars that the security section is weak. Isn't there a reference for this in the IPTEL document set? And, why is this document a direct submission rather than an IPTEL WG document? |
|
2006-04-26
|
05 | Brian Carpenter | [Ballot Position Update] New position, Undefined, has been recorded for Brian Carpenter by Brian Carpenter |
|
2006-04-26
|
05 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Undefined by Dan Romascanu |
|
2006-04-26
|
05 | Dan Romascanu | [Ballot comment] 1. I believe that the readability of the document would be improved if the acronyms would be expanded at the first occurence or … [Ballot comment] 1. I believe that the readability of the document would be improved if the acronyms would be expanded at the first occurence or in the terminology session. Some of the acronyms that could use such a help are URI, SIP, SIPS (in the title and Abstract) and B2BUA. 2. There is no separation of the References section into Normative and Informative |
|
2006-04-26
|
05 | Dan Romascanu | [Ballot Position Update] New position, Undefined, has been recorded for Dan Romascanu by Dan Romascanu |
|
2006-04-25
|
05 | Jon Peterson | State Change Notice email list have been change to br@brianrosen.net from brian.rosen@marconi.com |
|
2006-04-25
|
05 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley |
|
2006-04-25
|
05 | Sam Hartman | [Ballot comment] It would be good if this document gave (or perhaps better pointed to) some advice for how a user agent determines the context … [Ballot comment] It would be good if this document gave (or perhaps better pointed to) some advice for how a user agent determines the context to use. For example I don't know how the phone on my desk would be both usable, not require vendor-specific configuration and stick something reasonable in the context. I'm also not all that sure that the context needs to be reasonable. Presumably the target SIP server will just take the dialstring and dial it in many cases. |
|
2006-04-25
|
05 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman |
|
2006-04-25
|
05 | Magnus Westerlund | [Ballot discuss] * IANA consideration, third paragraph: This RFC defines a new parameter in the sub-registry, "phone- context", whose meaning and syntax are derived … [Ballot discuss] * IANA consideration, third paragraph: This RFC defines a new parameter in the sub-registry, "phone- context", whose meaning and syntax are derived from the same parameter in [RFC3969] As there is no "phone-context" parameter defined in RFC 3969 is it RFC 3966 that is intended in the above reference? |
|
2006-04-24
|
05 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Undefined by Lars Eggert |
|
2006-04-24
|
05 | Lars Eggert | [Ballot comment] Section 4: What's a "B2BUA?" Security considerations are weak ("normally should not be sent (...) without some kind of protection"). |
|
2006-04-24
|
05 | Lars Eggert | [Ballot Position Update] New position, Undefined, has been recorded for Lars Eggert by Lars Eggert |
|
2006-04-24
|
05 | Michelle Cotton | IANA Comments: Upon approval of this document, the IANA will add this document as a reference for the "user" SIP/SIPS URI Parameter. The IANA will … IANA Comments: Upon approval of this document, the IANA will add this document as a reference for the "user" SIP/SIPS URI Parameter. The IANA will also add "phone-context" to the SIP/SIPS URI Parameter registry located at the following: http://www.iana.org/assignments/sip-parameters Are there any predefined values for the phone-context parameter? (This question is appears to be similar to Magnus' discuss) We understand the 2 actions described above to be the only IANA Actions. |
|
2006-04-24
|
05 | Magnus Westerlund | [Ballot discuss] * IANA consideration, third paragraph: This RFC defines a new parameter in the sub-registry, "phone- context", whose meaning and syntax are derived … [Ballot discuss] * IANA consideration, third paragraph: This RFC defines a new parameter in the sub-registry, "phone- context", whose meaning and syntax are derived from the same parameter in [RFC3969] As there is no "phone-context" parameter defined in RFC 3969 is it RFC 3966 that is intended in the above reference? * First page header and abstract: Discuss Discuss: Should documents adding functionality to specification that has a registry also include Updates RFC xxxx or is this handled through the IANA registry? To me it seems a good thing if the RFC also is visable as updating the URI spec through the RFC inforamation thus adding an update statement would be positive. The downside is if there is many additions the reader of the RFC can get confused by the massive update list. |
|
2006-04-24
|
05 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to Discuss from Undefined by Magnus Westerlund |
|
2006-04-24
|
05 | Magnus Westerlund | [Ballot Position Update] New position, Undefined, has been recorded for Magnus Westerlund by Magnus Westerlund |
|
2006-04-21
|
05 | Jon Peterson | State Changes to IESG Evaluation from Waiting for Writeup by Jon Peterson |
|
2006-04-21
|
05 | Jon Peterson | Placed on agenda for telechat - 2006-04-27 by Jon Peterson |
|
2006-04-21
|
05 | Jon Peterson | [Ballot Position Update] New position, Yes, has been recorded for Jon Peterson |
|
2006-04-21
|
05 | Jon Peterson | Ballot has been issued by Jon Peterson |
|
2006-04-21
|
05 | Jon Peterson | Created "Approve" ballot |
|
2006-04-21
|
05 | (System) | Ballot writeup text was added |
|
2006-04-21
|
05 | (System) | Last call text was added |
|
2006-04-21
|
05 | (System) | Ballot approval text was added |
|
2006-04-20
|
05 | Jon Peterson | State Changes to Waiting for Writeup from AD Evaluation::AD Followup by Jon Peterson |
|
2006-03-07
|
05 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2006-03-07
|
03 | (System) | New version available: draft-rosen-iptel-dialstring-03.txt |
|
2006-02-06
|
05 | Jon Peterson | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jon Peterson |
|
2005-10-12
|
05 | Jon Peterson | State Changes to AD Evaluation from Publication Requested by Jon Peterson |
|
2005-07-27
|
05 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
|
2005-07-19
|
02 | (System) | New version available: draft-rosen-iptel-dialstring-02.txt |
|
2005-02-14
|
01 | (System) | New version available: draft-rosen-iptel-dialstring-01.txt |
|
2004-06-03
|
00 | (System) | New version available: draft-rosen-iptel-dialstring-00.txt |