Calling Line Identification for Voice Mail Messages
RFC 3939

[Ballot comment]
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?

[Ballot comment]
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?

[Ballot comment]
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).

[Ballot discuss]
If a terminal receives a Caller-ID telephone number via T1.401, how does it decide whether that number is an E.164 number or a 'local' number? If it is extremely problematic to make that determination (I suspect it is), why even draw the distinction for the purposes of this document?

Defining "local" (per 3.3) as "has meaning only within the domain of the voice mail system" seem unnnecessarily confusing to me, especially since this is the default. What does "domain" signify for a numbering plan? Does that mean that the number is a PBX-specific number (unroutable in the PSTN if you try to call it, so don't bother trying)? Or does it mean that it could be either PBX-specific or nationally-significant? The common case in T1.401 is to send a nationally-significant telephone number, which certainly doesn't only have meaning within the context of a voice mail system.

I also note that what is "local" to the generator of an VPIM message might not necessarily be "local" to the recipient of a VPIM message, in any meaningful sense of "local" that I could envision.

The concept of vendor-specific numbering plans (last sentence of 3.3) is foreign to me - device vendors do not typically assign numbering plans, though PBX operators often do. Is that what is meant here?

This document does not mention RFC2806 (the tel URL), or the bis currently underway. RFC2806 grappled extensively with the problem of representing various international, national and local dialing plans; for example, it defines a "phone-context" parameter that provides a closer approximation to what "local" probably wants to be. Similarly, although the document mentions RFC3161 in passing, it doesn't use or reference RFC3601. Seeing Yet Another Slightly Different BNF to portray telephone numbers within an RFC822-like header makes me fear for the compatibility described in Section 6.1 (the refusal of this document to use the leading '+' notation for internationally significant numbers seems especially counterintuitive). Were there any specific defects in RFC3601 and RFC2806 that made them inadequate for VPIM-CLID?

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot comment]
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?

[Ballot discuss]
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?

[Ballot discuss]
Some of the writing just doesn't make sense. For example, the fourth
paragraph of Section 1 starts "As a result", but I don't see what
that's a result of. The following sentence, about "future generation
of the proper Internet address", makes even less sense. (Note that
I'm talking about semantics, not grammar.)

3.2 is just as obscure. It says "requires provisioning for up to 15
digits", which sounds like a storage allocation requirement for the
program generating or accepting the Caller-ID header. But it then goes
on to speak of some telephonhy providers only supporting 10 digits,
and how it is better that "an international number NOT be truncated".
Why should implementations of this spec truncate the number? Is it a
comment on phone systems? If so, it's gratuitous. And the capitalized
NOT -- which isn't in 2119 -- should not be used in that case.

3.3 ties the dialing plan to the FQDN of the sender. That's wrong, or
rather, it's useless -- FQDNs can span numbering plan areas. Or
rather, there's no intrinsic link between an FQDN and any geographic
location, and hence a numbering plan.

The Security Considerations have little to do with security. The
information is useful, but shouldn't be presented in this section.

It would be nice if the phone number formats used here were compatible
with other Internet formats, i.e., that in RFC 3192 or in SIP URIs.
A gateway that receives phone numbers can certainly translate to such
formats; the translation back to a localized format can be done as
well by the ultimate recipient's machine.

AD review comments:

This document contains a lot of non-ASCII characters. These need to
either be replaced with an appropriate ASCII character or removed.

The abstract is repeated twice in the document. It should only be
present once, and it should not be a numbered section.

The abstract as it stands is a bit too short. I suggest changing
it to read:

  This document describes a method of identifying the originating
  calling party in the headers of a stored voice mail message.
  Two new header fields are defined for this purpose: Caller-id and
  Called-name. Called-id is used to store sufficient information for
  the recipient to call back, or reply to, the sender of the message.
  Called-name provides the name of the person sending the message.

The section on document conventions needs to be moved to appear
after the introduction.

A couple of examples showing RFC 2047 encoding of caller names
would be a useful addition to section 6.3.

This document defines an IANA-administered registration space for
numbering plans and defines two initial entries in this registry:
local and e164, but does not contain an IANA considerations section
defining the registry. This needs to be added. The section needs
to give the registry a name, reiterate the two initial entries in
the registry, and repeat that additional entries in the registry
require a standards track RFC.

The security considerations section talks a some length about how
this option can fail, but says nothing about the risks associated
with storing this information in messages. These risks need to be
described, e.g. that this document provides a means of placing
phone numbers in email and in doing so may reveal that information
in ways not previously anticipated.

The references in the document need to be split into normative and
informative groups.