Re: Pre-Last Call: VPIM v2 (Voice Profile for Internet Mail

Re: Pre-Last Call: VPIM v2 (Voice Profile for Internet Mail - version 2)

Ned Freed <Ned.Freed@innosoft.com> Wed, 04 December 1996 07:20 UTC

Message-Id: <01ICL91XIX5AA8C6DQ@INNOSOFT.COM>
Date: Tue, 03 Dec 1996 21:41:30 -0800 (PST)
Sender: owner-ietf-smtp@list.cren.net
Precedence: bulk
From: Ned Freed <Ned.Freed@innosoft.com>
To: gparsons@nt.com
Cc: mailext@list.cren.net, ietf-822@list.cren.net, ietf-smtp@list.cren.net, vpim-l@ema.org
Subject: Re: Pre-Last Call: VPIM v2 (Voice Profile for Internet Mail - version 2)
In-Reply-To: "Your message dated Mon, 25 Nov 1996 21:47 -0500 (EST)" <199611261435.JAA06397@list.cren.net>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

> Many of you are probably already aware of the Voice Profile for
> Internet Mail (VPIM) specification that was issued as Experimental
> RFC 1911 earlier this year.  The Electronic Messaging Association (EMA),
> with input from both the voice messaging and email industries, has
> recently completed a final version of VPIM (dubbed version 2) that is
> available as an Internet Draft <draft-ema-vpim-03.txt> and is attached
> to this message.  We have requested that the IETF Applications Area
> approve this specification as a Proposed Standard.

While I support this document and the profile it describes, there are at least
four procedural issues that I believe need to be resolved:

(1) The document calls for the use of application/directory objects. As far
    as I know application/directory hasn't yet been approved as a
    proposed standard, making this usage problematic.

    I fully expect application/directory to move onto the standards track
    in due course, so this problem will disappear on its own in the future.
    The issue then becomes one of timing -- is the reference to vCard
    formats worth holding up this document? I suspect that it is, but it is
    something to be considered.

(2) The document calls for the use of the CHUNKING and BINARYMIME
    SMTP extensions. These are both experimental protocols, and I know of
    nothing in the works to move them onto the standards track. As such,
    this usage is also problematic and is likely to remain so for some time.

(3) This document doesn't just profile existing services, it defines some
    new ones, e.g. the content-duration header field. I would much rather
    see the definition of any new services in a document separate from the
    service profile.

(4) I question the appropriateness of this document becoming a proposed
    standard. Modulo the definition of new services (which I think belong in
    a separate document anyway) it isn't a protocol definition, it is a
    profiling of several extant procotols defined elsewhere. The result
    feels a lot more like either a BCP or AS to me.

				Ned

Re: Pre-Last Call: VPIM v2 (Voice Profile for Int… Ned Freed