Voice Messaging Directory Service
RFC 4237

Received changes through RFC Editor sync (changed abstract to 'This document provides details of the Voice Profile for Internet Mail (VPIM) directory service. The service provides the email address of the recipient that is given a telephone number. It optionally provides the spoken name of the recipient and the media capabilities of the recipient.

The VPIM directory Schema provides essential additional attributes to recreate the voice mail user experience using standardized directories. This user experience provides, at the time of addressing, basic assurances that the message will be delivered as intended. This document combines two earlier documents, one from Anne Brown and one from Greg Vaudreuil, that define a voice messaging schema into a single working group submission. [STANDARDS-TRACK]')

[Ballot comment]
Positive review:  I've double-checked the enum wg's look at vpim-routing's registration of
two enumservices.  These match the new format that the enum wg has requested of IANA,
and they look right.

New material in the Security Considerations for how to implement
privacy as needed (support DIT and look toward the auth draft
when it finally progresses) cleared my Discuss.

[Note]: 'IANA Comments:
Upon approval of this document the IANA will register a LDAP OID as well as the descriptors defined in this document.
' added by Michelle Cotton

Review by Spencer Dawkins, Gen-ART:

I don't see any reason NOT to publish this draft as a proposed
standard.

I was slightly tickled by the "go fish" security consideration - is
this terminology new in this draft?

[Ballot comment]
Does the current text on vPIMTelephoneNumber in 3.1 of vpimdir intentionally exclude useful non-E.164 numbers (like, say, freephone numbers, which are necessarily national-specific), or is this an unintended potential interpretation of saying that the telephone numbers that appear in this attribute are E.164 numbers?

[Ballot comment]
Does the current text on vPIMTelephoneNumber in 3.1 intentionally exclude useful non-E.164 numbers (like, say, freephone numbers, which are necessarily national-specific), or is this an unintended potential interpretation of saying that the telephone numbers that appear in this attribute are E.164 numbers?

[Ballot comment]
Positive review:  I've double-checked the enum wg's look at vpim-routing's registration of
two enumservices.  These match the new format that the enum wg has requested of IANA,
and they look right.

[Ballot discuss]
In vpimdir's security considerations, regulatory requirements are discussed:

      No such protection [caller-id blocking]
      is curently available on the Internet.  The
      protection of this data is essential, but is up to the individual
      service providers to appropriately limit disclosure of this
      information.

In what context is this the case?  An anonymous caller-id is available for
SIP (RFC 3323).  It seems appropriate to advise specifics of providing
access control and other privacy mechanisms for both the directory
(LDAP) - see the most recent draft of ldapbis-dn and lsdapbis-models -
and for the callers (unless I've misunderstood what kind of callers are
accessing VPIM).

[Ballot discuss]
draft-ietf-vpim-routing-09:

    Section 3.1 talks about the consequences of the DNS entry being
    maliciously corrupted so that the client gets directed to the
    wrong LDAP server.  It should also talk about the consequences
    of the LDAP attribute being maliciously corrupted so that the
    client gets directed to the wrong voice mailbox.

  draft-ietf-vpim-vpimdir-10:

    What integrity, authentication, and access control mechanisms
    will be used?  These topics should be discussed in section 4.
    At a minimum, the following two documents should be referenced:
   
      [1]  Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
          "Authentication Methods for LDAP", RFC 2829, May 2000.

      [2]  Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory
          Access Protocol (v3): Extension for Transport Layer
          Security", RFC 2830, May 2000.

[Ballot comment]
draft-ietf-vpim-routing-09:

    s/Overview/Abstract/

    Please merge the Overview and Abstract.  The result should
    be an Abstract before the Table of Contents.

    Please delete the last paragraph of the Overview prior to
    publication as an RFC.

  draft-ietf-vpim-vpimdir-10:

    Please merge the Overview and Abstract.  The result should
    be an Abstract before the Table of Contents.

    Please delete the last paragraph of the Overview prior to
    publication as an RFC.

    Please delete the Working Group Summary section prior to
    publication as an RFC.

[Ballot discuss]
Security does not seem to be handled by the VPIM message routing
service even in the LDAP model.

In particular, there is no way to interoperably know that I have not
been maliciously redirected to the wrong LDAP server.  Even if TLS is
used, the traditional LDAP rules about certificate matching will be
inappropriate for this application.

More AD review comments:

draft-ietf-vpim-vpimdir:

1. You really need to give IANA specific instructions in this section.
Please list all of the objects that need to have identifiers assigned.  If
IANA has to go digging through the document to interpret and find them, some
will be missed.  Make their job easy, please.

2. The reference for UTF-8 needs to be complete.  "RFC 3629" just isn't
enough.  Same format as was used for [CONTEXT], please.

draft-ietf-vpim-routing:

1. Same comment on the updated references.

2. Please add an IANA Considerations section.  It should say something like
"This document does not require any IANA actions." if there are no IANA
considerations.

ENUM WG review requested and completed.  Per Greg: "We received comments from Sophie Coste-Martinez that I need to use to turn a new version of the document".

AD review comments before last call:

draft-ietf-vpim-vpimdir: The IANA Considerations section notes that private OIDs are being used, and loosely suggests that "IANA will provide a replacement value from the IANA standards branch".  There should be a specific registration request in this section.  Is this the "IANA standards branch" being described?:

http://www.iana.org/assignments/ldap-parameters

RFC 2279 (UTF-8) has been obsoleted by RFC 3629.  Which reference is appropriate?

draft-ietf-vpim-routing: The abstract in section 1 is missing.

I'd like to have the ENUM working group review this document, too.  I'll ask them to do so.

RFC 2915 has been obsoleted by RFCs 3401, 3402, 3403, and 3404.  Which reference is appropriate?

RFC 2916 has been obsoleted by RFC 3761.  Which reference is appropriate?