Calling Line Identification for Voice Mail Messages
RFC 3939

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).

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.

  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
  draft-klyne-msghdr-registry?

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?