Internet Voice Messaging (IVM)
draft-ietf-vpim-ivm-06

[Ballot comment]
I removed my Discuss on the lack of negotiability/upgradeability of the codecs
because it's not IESG's job to second-guess strong WG consensus.  WG Chair wrote:

After much discussion, of the various negotiation options (from explicit
with CONNEG to implicit using DSN) we chose not to specify the codec
negotiation.  This was more because the vendors and providers that were
participating in the discussion suggested it would typically be
pre-provisioned and did not want a mechanism forced on them.  The value of
IVM was in setting the baseline, not in specifying a negotiation mechanism
that should be used.



------

The originator's spoken name MAY be included with messages as separate
audio contents, if known, and indicated by the Content-Disposition
VOICE parameter as defined in VPIM v2 [VPIMV2].  If there is a single
recipient for the message, their spoken name MAY also be included (per
VPIM v2). A spoken subject MAY also be provided (per VPIM v2).

There is either a too subtle distinction btw this MAY and the SHOULD
above, or the MAY downgrades the SHOULD.

---

---

Typo:  use and onramp/offramp  s/and/an

---
Typo:

The VOICE parameter on Content-Disposition from VPIM v2 [VPIMV2]
SHOULD be used to identify the any spoken names or spoken subjects (as
distinct from voice message contents).

s/the any/any

---

[Ballot comment]
> client SHOULD implement to allow recipient's to display voicemail

s/recipient's/recipients/

There are an awful lot of normative references to IDs. Is this
document going to sit in the RFC editor queue for an extended period
of time?

[Ballot comment]
---

Typo:  use and onramp/offramp  s/and/an

---
Typo:

The VOICE parameter on Content-Disposition from VPIM v2 [VPIMV2]
SHOULD be used to identify the any spoken names or spoken subjects (as
distinct from voice message contents).

s/the any/any

---

The originator's spoken name MAY be included with messages as separate
audio contents, if known, and indicated by the Content-Disposition
VOICE parameter as defined in VPIM v2 [VPIMV2].  If there is a single
recipient for the message, their spoken name MAY also be included (per
VPIM v2). A spoken subject MAY also be provided (per VPIM v2).

There is either a too subtle distinction btw this MAY and the SHOULD
above, or the MAY downgrades the SHOULD.

---

[Ballot discuss]
Interopability concern:
The must-implement audio formats are both toll-quality.  There isn't foresight for
interoperability with voicemail generated by  with a current mobile or 3G
mobile, which would not support these formats - though this is a binding of
VPIMV2R2, is it necessary to be limited by that?

Protocol police nit:
VPIMV2R2 often cited normatively needs to be a normative ref.

[Ballot discuss]
Interopability concern:
The must-implement audio formats are both toll-quality.  There isn't foresight for
interoperability with voicemail generated by  with a current mobile or 3G
mobile, which would not support these formats - though this is a binding of
VPIMV2R2, is it necessary to be limited by that?

[Ballot comment]
This draft was reviewed by Spencer Dawkins, Gen-ART

His comment:

This document is roughly ready for publication as a Proposed Standard,
but I have to say that I really can't figure out what the "new
standard mechanism for representing a voicemail message within
SMTP/MIME" mentioned in the Introduction might be!

I note that there are no IANA considerations, which bothers me if
we're really adding a "new standard mechanism". Is the idea just that
we're reusing lots of standard stuff in a way we haven't used it
before?

I didn't see anything I disagreed with or couldn't understand, except
for this gaping hole, plus one nit ("Finally is explained how..."
should be something like "Finally we explain" - just fix the wording).

[Ballot discuss]
This is a borderline DISCUSS. I'd like to hear the group's response to Spencer's comment - the point about this document having little comment from outside the WG might be just right.

Full review (11K) available at http://www.alvestrand.no/ietf/gen/reviews.
Summary:

  * This draft is on the right track but has open issues,
    described in the review.

The biggest "open issue" is that this requirements document has some
really vague "MUSTs" that need to be spelled out in more detail. For
example, "and MUST gracefully handle the case where a legacy receiving
system does not support the IVM codecs" - if the working group is
going to use this document as a filter for proposals that don't meet
the MUSTs, how would anyone know whether a proposal meets this MUST?

In general, the requirements that include the words "specifically,
this includes" are fine. It's the ones that don't include these words
that have problems!

[Ballot discuss]
The security considerations section says:

It is anticipated that there are no additional security issues beyond
those identified in VPIM v2 [VPIMV2R2] and in the other RFCs
referenced by this document, especially SMTP [DRUMSMTP], Internet
Message Format [DRUMSIMF], MIME [MIME2], Critical Content [CRITICAL]
and Message Context [HINT].

This seems to me only true if you ignore the mechanism for interoperability
between IVM and VPIM.  10.3 implies a gateway not previously implied
by the above doc set, for exmaple.  Either the security considerations
section needs to call out the issues in that area, point to the parallel
between those and one of the existing sets of security considerations
in a more explicit way, or draft a statement punting that issue and
explaining why it is okay to punt it.

[Ballot comment]
This text in section 8>

  A sending implementation MAY determine the recipient capabilities 
  before sending a message and choose a codec accordingly (e.g., using
  some form of content negotiation).

concerns me.  Without a reference to an appropriate content negotiation
mechanism, it would seem better to use language like the "unless the
originator is aware" phrase above.

I'm also a bit concerned by the "other" MAYs in the table given, as there seems
to be more of a restriction here--MUST NOT unless prior knowlege
permits is closer, where MAY seems to close to open to choice.  I'm not sure
what to suggest here other than removing the other row, which seems too extreme.

[Ballot comment]
>5. Transport
>
>The message MUST be transmitted in accordance with the Simple Mail
>Transport Protocol, as updated by the DRUMS working group [DRUMSMTP].

Does this mean that an SMTP->UUCP gateway MUST bounce the message instead of forwarding it?

Does this mean that a web server MUST NOT use this message format?

If so, why?  If not, what does it mean?

[Ballot comment]
(25 March 2004)
The draft seems to mandate compliance with 2821 and 2822.  My impression was that the email community was not yet willing to take that step, especially given the stanards level of 821 and 822.  Is this document correct?

AD review comments returned to WG:

The VPIM acryonym needs to be expanded in the abstract.

Section 4 states, in part:

  Any content type is permitted in a message, but the top level content
  type on origination of a new, forwarded or reply voice message SHOULD
  be multipart/mixed. If the recipient is known to be VPIM v2 compliant
  then multipart/voice-message MAY be used instead (in which case all
  the provisions of [VPIMV2R2] MUST be implemented in constructing the
  message).

This places certain constraints on senders but none on receivers. I would like
to see some requirements placed on receivers. A minimum would be a reference to
RFC 2049's requirements for multipart handling.

Section 8 states, in part:

  In the absence of such recipient  knowledge, sending implementations MUST use
  raw G.711 mu-law l  indicated with a MIME content type of "audio/basic" and
  with a  filename parameter that ends ".au" [G711],[MIME2].

Do we really want to require a content-disposition filename parameter ending
in .au? I'd be a lot more comfortable with making this a SHOULD.

Refences need to be split into normative and informative groups.

[CRITICAL] should be updated to refer to RFC 3459.

[DSN] should be updated to refer to RFC 3461. Also, should RFCs 3462-3464 also
be referenced since they are all part of NOTARY that needs to be supported?

[HINT] should be updated to refer to RFC 3458.

This document is missing the IPR boilerplate required in standards track
documents by RFC 2026 section 10.4.