The ENUM Dip Indicator Parameter for the "tel" URI
RFC 4759

Note: This ballot was opened for revision 05 and is now closed.

(Cullen Jennings) Yes

(Jon Peterson) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Brian Carpenter) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2006-06-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Section 9.2., paragraph 0:

 9.2.  Informative References

        Nit: idnits says:
        - Unused Reference: [7] is defined on line 259, but not referenced
        - Unused Reference: [8] is defined on line 262, but not referenced
        - Unused Reference: [9] is defined on line 265, but not referenced

(Bill Fenner) No Objection

(Ted Hardie) (was Discuss) No Objection

Comment (2006-06-21)
No email
send info
Original DISCUSS:

Did the working group discuss the possibility of using this parameter to indicate which ENUM database was  checked (e.g. enumdi=e164.arpa, or something similar?).  Given the prevalence of "private ENUM", the ability to indicate that the local "private ENUM" was checked instead of or in addition to e164.arpa might be valuable.  That would, though, change both the syntax and the number of times the parameter might appear.  (Note:  I would like to discuss this point, but I do not believe it should be blocking, and I will update the position to a non-blocking one after discussion, whatever the outcome).

Reply from jdr:

Indeed, this was discussed quite a bit. Earlier versions of the enumdi draft had exactly the parameter you are talking about, indicating a specific root in which the dip had been don

We eventually decided not to move forward with that. The reason was, nothing in the current ENUM specifications describes how to do enum in anything besides e164.arpa, so it seemed out of plcae for the enum dip indicator to first introduce non e164.arpa roots. Furthermore, there are various proposals on the table for how private enum will work, and some of them involve the use of different service types, for example. Thus, its not clear, until that work is complete, what the right way would be for the enumdi to indicate a specific root in which the lookup occurred.

(Sam Hartman) (was Discuss) No Objection

(Russ Housley) No Objection

(David Kessens) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

Magnus Westerlund (was No Record, No Objection) No Objection

Comment (2006-06-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
"3.  Formal Syntax

   The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) as described in RFC4234 [2].

   parameter =/ enum-dip-indicator

   The ENUM Dip Indicator is an optional parameter for the "tel" URI,
   and so the enumd-dip-indicator production above is an example of the
   parameter syntax element described in [5], with "enumdi" being an
   example of the pname production described there."

Section 5:

Are the UK example numbers taken from an reserved range? Or they part of publicly assigned numbers?

In my view the above should be clear about which syntax it expands. Thus I would suggest that one change the sentence to:

   The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) as described in RFC4234 [2] to extend the syntax of the [RFC3966] defined "parameter" element.

I think the following sentence: 
  "The ENUM Dip Indicator is an optional parameter for the "tel" URI,
   and so the enumd-dip-indicator production above is an example of the
   parameter syntax element described in [5], with "enumdi" being an
   example of the pname production described there."

Is in error as the syntax definition uses "=/" rather than a normal "=" for assignment. Due to that the formal syntax do define it is an extension, it can't be a example of the syntax for parameter. Although it clearly follows it.