Glenn Parsons (gparsons@nortelnetworks.com)
Tue, 20 Mar 2001 18:10:09 -0500
Folks,
Apologies for the delay, but here at long last are the full minutes from our
last meeting...
Perhaps reading them will remind us if there are any hot issues to discuss
on Friday :-)
Cheers,
Glenn.
Voice Profile for Internet Mail WG (vpim)
IETF 49 Friday, December 15, 2000
====================================
Chairs: John Noerenberg <jwn2@qualcomm.com>
Glenn Parsons <gparsons@nortelnetworks.com>
Notes by: John Noerenberg <jwn2@qualcomm.com>
Agenda Bashing
We started with the usual agenda bashing. Glenn noted that since we've
eliminated the requirements for partial delivery notification, we can
drop the PDN doc from our to-do list. Once the agenda was sufficiently
beaten into submission, we moved onto reviewing the status of our
charter.
Charter Review
For the charter we discussed where we were w/r/t VPIM v2 docs, IVM docs,
and how that matched up with our milestones. After consultation with
the document editors, and observation of how things stand, we've move
the due dates out by 3 months. The aim is it get the IVM docs to
PROPOSED status by the March meeting. At that point we (hopefully) go
into Fin_Wait while the IESG considers and approves the docs for
PROPOSED status. VPIM v2 is nearly ready for DRAFT status now, which
was our next topic.
VPIM v2 to Draft
Greg believes he has removed the last ambiguities in the wording.
There's still a problem with normative references to RFCs which are not
already at DRAFT or ready to move there. The VCARD text/directory
references have been dropped. DSNs were tested at the bakeoff. There
should be sufficient information to the DSN RFC along. MDNs are still
unresolved. John Noerenberg will have another go at this, at least
identifying what is required. Ned Freed offered to publish a
requirements matrix for MDNs and invite comment from implementers.
Greg described the differences in the revision. There were several
notable changes. VPIM fax-only messages may be sent according to IFAX
rules, and need not be multipart/voice messages. VPIM v2 implementations
should not send text parts, but they may not reject a message if they
receive a message containing a text part. They are not required to
render the text part, but a message including a text part should not be
rejected.
Bakeoff Results
Glenn reported on the results of the bakeoff. Detailed results can be
found at http://www.vpim.org/conformance/conformance.html. Thirteen
products were included in the testing. Apparently, Pillsbury is not
happy over the abuse of their trademark "Bakeoff" and is suing. The
Note taker failed to record who is being sued. Noteworthy results at the
<ahem> meeting, were that most products could handle simple messages,
and most required numeric local parts for the email address. The
attendees indicated their preference for numeric local parts in the From
header. Glenn will try to organize another <ahem> conformance test
meeting for February.
Fax Update
There was a brief update from the FAX WG, ietf-fax-minaddr and
ietf-fax-faxaddr are ready to move to DRAFT status.
VPIM Address Draft
GSTN phone numbers have some preferred forms. The purpose of this
document is to harmonize VPIM voice mailbox addressing with the GSTN
forms for the To header. The draft doesn't require From headers conform
to these rules. The draft also adds IANA registration of the LHS forms
indicating the local part is to be interpreted as a voice mailbox.
During the meeting we concluded the WG should provide more guidance on
recommendations for V2 voicemail addresses. Please provide comment on
the mailing list before this is sent for IESG last call.
ENUM WG Update
Rich Shockey provided an update on work in the ENUM WG. Most of its
documents will be classified as INFORMATIONAL. There was to be a
meeting in Washington to brief staffers from the US Congress on ENUM
plans and requirements. In addition there is an ITU meeting planned for
mid-January where IETF ENUM work will be discussed. Rich anticipates
that public (online?) directories will be announced in early 2001, and
that VPIM systems should be able to query the directories. It is likely
an ENUM interoperability WG will be formed to help deployment, as well
as publication of BCPs on ENUM practice. It is also possible that SIP
will be incorporating ENUM rules into its protocols.
VPIM Routing Draft
The VPIM routing draft describes a method of using ENUM + LDAP to
determine how a client can determine the destination for a VPIM message.
There aren't any issues that have been raised with this draft. It has
been rewritten to use NAPTR records instead of PTR/SRV records. This is
consistent with ENUM's direction. Based on the lack of comment, the
chair believes this can go to WG Last call in January, then be submitted
to the IESG for consideration as PROPOSED. During the meeting some
editorial comments were promised.
VPIM Directory
The current VPIM directory draft is the result of combining Anne Brown
and Greg Vaudreuil separate work to define an LDAP schema for VPIM
directory entries. It must be verified that the attribute names that
are chosen in the draft are consistent with other LDAP Schema. There
are some errors in the BNF which Anne will fix. Some concern was
expressed regarding the length of 32kADPCM encoded spoken voice. There
is no way to negotiate this within LDAP so a single codec must be agreed
on. The Chair would also like this draft to be considered by the WG for
Last Call during January.
We then moved on to the Internet Voice Mail documents (previously known
as VPIM v3).
IVM Goals
Emily Candell reviewed the goals document. Principally, it is about
interoperability with existing Internet email. This includes desktop
email clients, Internet voice mail systems, unified messaging systems,
and traditional email servers. There is less concern with backward
compatibility to V2 systems than originally expected. The WG should aim
for this document to become an Informational RFC.
IVM Specification
Stuart was unable to attend the meeting, but Glenn presented the slides
Stuart prepared. His work since the last meeting was to align the IVM
specification with other drafts of the WG. He has removed references to
PNDN, since PNDNs no longer exist. He has clarified behavior with
respect to multipart/report messages. The draft now reads that a
message MAY contain a single recipient's spoken name. He has also noted
that the baseline codec may become G.711, instead of the previously agreed
codec of WAV/MS-GSM. While making these changes he took the opportunity
to make other minor editorial changes.
Message Context
The Content Hint draft has been recast as Message Context. It's intent
is now to describe in the message headers the context in which the
message can be interpreted, rather as a directive as to how a message
should be interpreted. The draft adds a new message header called
Message-Context that may optionally appear with the other headers that
precede the message body. By including this in the headers, context
information is available without parsing the body of the message. The
draft defines a set of context values for the header, plus the IANA
registration rules necessary to expand the list.
Remaining work on this draft includes fixing the abnf of the syntax for
the header, and more carefully describing the security implications.
The language of sections 6 and 7 should be edited for clarity.
Discussion about the draft raised the question of the header's utility.
It doesn't require any specific interpretation of the content by the
receiving UA upon receipt of the header , and generating it is optional
for the sender. Use of the header could enable UAs to present
information about incoming messages such as message type icons in
message summary windows, displaying the sender's phone number, or
presenting information about the size of the message based on the type
of the message content.
Because use of this header is optional for senders to send and receivers
to process if encountered, perhaps this document would be better as an
informational RFC rather than one which defines standardized protocol.
Critical Content
Discussion of the Critical Content draft dealt with the interaction of
gateways and MTAs over handling of messages consisting of multiple media
types. The distinction was drawn that a gateway inspects the contents
of a message in order to determine whether it can be delivered while a
MTA simply relays messages based on the address information carried in
the recipient headers.
Practical experience is that gateways are not only functionally separate
from MTAs but also operate on a different node than the MTA. Some
gateways will generate messages to MTAs to send a DSN, however some
generate MDN. The WG members in attendance concluded that DSNs SHOULD
be used, but MDNs MAY be used. DSN use should be encouraged. UAs have
the freedom to not generate MDNs at the user's preference, so DSNs were
considered to be a more reliable mechanism.
An open issue for use of this header is how it interacts with IMAP.
IMAPExt
There are some desirable extensions for IMAP to enable VPIM services to
extract binary content from message sub-parts. In addition, it would be
useful to use some other protocol, such as RTSP, to extract voice
sub-parts from a message store. Currently IMAPExt has no plans to
develop extensions along these lines. If IMAP extensions like this are
useful for VPIM systems, a WG to develop them needs to be found or
established.
Codecs
The meeting concluded with a discussion of the codecs, in particular,
the status of the use of WAV. The WAV internet-draft was not correct,
and those errors need to be fixed. Informational RFC 2361 describes the
Microsoft registries for WAVE and AVI registries. It was asserted at
the meeting that Microsoft has placed no restrictions on the use of the
WAV codec header.
There is no MIME sub-part audio/ms-gsm. It could be referenced as
described in the IVM draft (ivm-01) as "audio/wav; codec=31", however, it
wasn't certain at the meeting if Microsoft's definition is adequately
documented for use by others. ivm-01 notes the idea of adopting G.711
(mu-law) instead of ms-gsm, but currently requires the use of ms-gsm.
G.711 would offer better voice quality. This must be resolved
definitely. For VPIM v2 compatibility, the use of G.726
(audio/32kadpcm) is allowed.
End of Meeting
We were out of time for the last session on the last day. We hurriedly
called an end to the discussion, and expected more discussion on the
vpim mailing list regarding the open issues we discussed at the meeting.
--
This archive was generated by hypermail 2.0b3 on Wed Mar 21 2001 - 02:24:07 IDT