Internet Voice Messaging (IVM)
RFC 4239

Note: This ballot was opened for revision 06 and is now closed.

(Scott Hollenbeck) Yes

(Harald Alvestrand) (was Discuss) No Objection

Comment (2004-04-02)
No email
send info
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).

(Steven Bellovin) No Objection

Comment (2004-03-25 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
(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?

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

Comment (2004-03-28 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
>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?

(Ted Hardie) (was Discuss) No Objection

Comment (2004-03-29)
No email
send info
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.

(Russ Housley) No Objection

(David Kessens) No Objection

(Allison Mankin) (was Discuss) No Objection

Comment (2004-05-13)
No email
send info
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

---

(Thomas Narten) No Objection

Comment (2004-04-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
> 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?

(Jon Peterson) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) No Objection

Comment (2004-04-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Needs an IPR section