Calling Line Identification for Voice Mail Messages
RFC 3939

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

(Ned Freed) Yes

(Scott Hollenbeck) Yes

(Harald Alvestrand) No Objection

Comment (2004-04-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Reviewed by John Loughney, Gen-ART.
Caller-ID is capitalized inconsistently.
There is no IPR section (but RFC Editor will fix that).
Note on section 4: I don't like using RFC 2047 "any charset", but the purpose of the extension is not making the information readable to all, it's preserving the data that came off the telephone interface. If we accept the purpose, it kind of makes sense - unfortunately.

(Steven Bellovin) No Objection

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

Comment (2004-04-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
5.3 Examples
       Caller-ID: 6137684087
       Caller-ID: 6139416900

Are these supposed to be representing internal calls?  They look awfully like Ontario phone numbers but they are not in the format specified in 3.2 (no CC).

(Ted Hardie) (was Discuss) No Objection

Comment (2004-04-02)
No email
send info
In Section 3.3, numbering plans, the document says this:

  In this baseline case (i.e., analog lines), no numbering plan 
  information is known or implied.  However, in the case that a 
  numbering plan is known, an optional "NumberingPlan" parameter MAY
  be used to indicate the semantic.  Only two semantics are defined _ 
  "local" and "e164".  "local" is the default if no numbering plan 
  semantic is included.  Further, "local" has meaning only within the 
  domain of the voice mail system that stored the message.  "e164" 
  indicates that the number is as described in [E.164]. 
  "x-" may be used to indicate vendor specific dialing plans.

How the "x-" values would actually be used is not at all clear, and
given the failures we've seen with x- in other contexts, I think more
text is needed.  In particular, if we're talking about vendor-specific
formats,instead of numbering plans, we need more details.  If
x-example might have a "+" character because Example's phone
switch presents a number with one, does this allow that?  Or do
we mean x-example2 might reverse the presentation of extension 
and base number from the typical, but they are all still numbers?

The use of phone numbers in 6.2 may present a problem; they may not
now be valid numbers but could be in the future.  In a previous document,
we used a UK range set aside for these examples; could we reuse
that range or an equivalent?

(Russ Housley) No Objection

Comment (2004-03-30 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  Section 3: s/external cal/external call/
  Section 4: Why not accommodate UTF8 now?  I would think that telephone
  systems will start supporting more robust international character
  encoding schemes in the future.

  Shouldn't we ask IANA to add these to the registry established by

(David Kessens) No Objection

(Thomas Narten) No Objection

(Jon Peterson) (was Discuss) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) No Objection

(Allison Mankin) No Record

Comment (2004-04-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I have another concern about the IANA registry for the ietf-token:

The ietf-token for the Caller-ID numbering plan seems
valueless.  It is optional that it ever appear, so it cannot
be counted on for any help in understanding the numbers, or
solving truncation or other problems.  Registration of official
ones is strict, but there are x-tokens which require no
registration.  What's the point of using this token or bothering
with this registry?