Glenn Parsons (gparsons@nortelnetworks.com)
Fri, 17 Aug 2001 18:19:24 -0400
Folks,
Please review the following minutes from IETF 51. I will send them in as-is
if I there are no comments by Aug 24th. FYI, the presentations are on the
VPIM website at: http://www.ema.org/vpim/meetings/minutes.html#ietf
Cheers,
Glenn.
> ----------
>
> VPIM Meeting Minutes, IETF 51, London
> By: Stuart McRae <stuart.mcrae@uk.ibm.com>
> Chair: Glenn Parsons <gparsons@nortelnetworks.com>
>
> John Noerenberg has resigned as co-chair due to a change in his area of
> focus. The IESG is considering whether it is worth replacing him as the
> group is so near to completing its work
>
> The Agenda was reviewed and agreed.
>
> 1. VPIM Charter & Milestones review (Glenn Parsons)
>
> We are currently using www.ema.org/vpim as the repository for VPIM
> information, but hope to have vpim.org back soon (or another dedicated
> VPIM site).
>
> The charter deliverable documents were reviewed. Most documents are in or
> ready to enter Working Group last call. Milestones have been updated as
> appropriate. This could be the last meeting of the group, or we may meet
> next time, depending on whether issues/loose ends remain to be cleared up.
> We also need to consider if we want to recharter and do additional work,
> so that may be a topic of conversation for the next IETF.
>
> 2. VPIM v2 r2 - 30 minutes
>
> 2.1 Voice Profile for Internet Mail - version 2 (Greg Vaudreuil)
>
> - draft-ietf-vpim-vpimv2r2-03
> - draft-ietf-vpim-vpimv2r2-32k-01
> - draft-ietf-vpim-vpimv2r2-dur-01
>
> The vpimv2r2 document now includes the IANA registration instead of having
> it as a separate document. These documents have completed working group
> last call and have gone to the IESG.
>
> 2.2 MDN drafts (Greg Vaudreuil )
>
> Following discussions with folks present this week, Greg is close to
> having a document ready to post as a first draft revision of RFC 2298.
>
> Only dispositions that seem to be implemented are "deleted" and
> "displayed". So the plan is to delete the others in the draft as not
> tested. Others that are useful can be built later as extensions (e.g. the
> fax working group have done further work in this area).
>
> The objective is to get lots of review of the first draft and expect
> people to speak up if they have implemented things that are deleted. The
> key is therefore to get all the working groups who have used MDNs to
> review the draft.
>
> Disposition Modifiers do not seem to be implemented. Therefore the
> proposal is to delete all except the extension modifier. It is assumed
> that no implementation experience is necessary to for a generic extension
> mechanism.
>
> Greg requested clarification on the requirement for implementations. Ned
> responded that two senders and two receivers are enough - though more is
> better. We will need a list of which features are implemented in different
> implementations.
>
> Greg will add additional advice on gatewaying to his draft.
>
> There will be just one document. The title of the document will be revised
> to more accurately express the fact that it is self contained.
>
> 2.3 DSN drafts (Greg Vaudreuil)
>
> - draft-moore-1891bis-00
> - draft-vaudreuil-1892bis-00
> - draft-vaudreuil-1893bis-00
> - draft-vaudreuil-1893ext-00
> - draft-vaudreuil-1894bis-00
>
> These drafts revise RFC1891-RFC1894.
>
> Greg is working with the IETF Editor to delete the "1983" draft that
> appeared due to a typographical error in the filename during submission!
>
> The draft-vaudreuil-1893ext-00 draft is being used to collect additional
> status codes that need to be added.
>
> Ned Freed said he would also put out a revision to RFC2034 (which is also
> mentioned in VPIMv2)
>
> All of these documents refer to RFC821 and RFC822. They should remain this
> way until it is clear whether either of the updates (2821 and 2822) are
> going to have to be cycled.
>
> These documents will stay as individual contribution, so Greg will tell
> Ned when they are ready for IETF Last Call.
>
> 3. VPIM Addressing (Glenn Parsons)
>
> - draft-ietf-vpim-address-01
>
> This document has completed working group last call and it has gone to the
> Area Directors for review.
>
> The Fax addressing drafts have now been approved and will be published as
> Draft Standard. There is some concern that the broader applicability of
> this work beyond fax is not being recognised. Claudio has therefore
> requested that the IESG add a note to the generic document to indicate its
> applicability beyond fax. Ned is investigating if this is possible.
>
> 4. ENUM Update (Glenn Parsons)
>
> ENUM is thinking of rechartering and coming back into existence to figure
> out some deployment issues.
>
> 5. VPIM Directory (Greg Vaudreuil)
>
> 5.1 Voice Message Routing Service
>
> - draft-ietf-vpim-routing-01 (expired)
>
> This draft has expired. It was based on ENUM feedback. The intention is to
> post a new draft that updates the date only. Comments/review is requested
> from anyone considering/implementing this. Greg expects to see more
> activity/trials in this space.
>
> What should we do if the VPIM work group terminates? Does this become an
> individual submission, or do we finalise it and submit it? The consensus
> was that we should last call it the document as it is, and then it can be
> redone if ENUM changes (it is currently consistent with current ENUM
> documents).
>
> 5.2 Voice Messaging Directory Service (Schema)
>
> draft-ietf-vpim-vpimdir-00 (expired)
>
> This work is stalled because Anne has left the industry. Glenn is going to
> take over getting this revised and posted.
>
> There are no known outstanding issues. The ASN1 and BNF need to be cleaned
> up, the codec identification added, and it needs to be made a subclass of
> inetOrgPerson (rather than stand alone).
>
> 6.0 IVM
>
> 6.1 Internet Voice Mail Requirements (Glenn Parsons)
>
> - draft-ietf-vpim-ivm-goals-03
>
> The Working Group Last call is complete as an Informational document. It
> has gone to the Area Directors for review.
>
> 6.2 Internet Voice Messaging (Stuart McRae)
>
> - draft-ietf-vpim-ivm-02
>
> The IVM draft has been updated in preparation for completion, removing
> editorial comments, making minor clarifications, updating the
> bibliography, reflection completion of the DRUMS revision, and aligning it
> with the latest co-dependent drafts (Message Context, Critical Content).
> It currently refers to both www.vpim.org and www.ema.org/vpim.
>
> One correction was made - if a VPIMv2 message is created it MUST conform
> to the VPIMv2r2 RFC.
>
> The other technical change was based on the codec consensus that an IVM
> Message SHOULD contain an audio/wav or audio/ basic content (except when
> it knows what else the recipient supports - e.g. VPIMv2). As a result the
> updated Codec table states that an IVM implementation:
> - MUST read "audio/wav, codec=31" and audio/basic
> - MUST write "audio/wav, codec=31" or audio/basic
>
> +----------+--------+----------+--------+----------+
> | | No VPIMv2 Support | VPIMv2 Support |
> +----------+--------+----------+--------+----------+
> | Codec | Record | Playback | Record | Playback |
> +----------+--------+----------+--------+----------+
> | MS-GSM | MAY* | MUST | MAY* | MUST |
> | G.711 | MAY* | MUST | MAY* | MUST |
> | 32KADPCM | MAY | MAY | MUST | MUST |
> | Other | MAY | MAY | MAY | MAY |
> +----------+--------+----------+--------+----------+
> * MUST record at least one
>
> Stuart went on to highlight some specific facts of interest about the
> current draft to ensure there was consensus ready for the last call
> (comments on these items will be solicited on the list):
>
> * The draft states that you SHOULD create a message with a Message-context
> of voice-message - so what makes something an IVM message, if not that it
> has a Message Context of voice-message? The advantage of allowing IVM
> messages which do not contain a Message-context is that existing e-mail
> clients can conform (which is a goal). This could be achieved by leaving
> this as SHOULD, or reworded it to "The message header MUST indicate a
> message context of "voice-message" if the sender support Message-context
> (see [HINT])."
>
> * If a Message-context of voice-message is not required, what makes a
> message an Internet Voice Message? Does it have to contains an approved
> voice content type (or rather any voice content type, as this is
> permitted)? Can a message with no voice content be an IVM? This is
> permitted for a Message-context of voice-message, but does it make sense
> for an Internet Voice Message? This could be addressed by rewording the
> requirement on content type as follows: "An Internet Voice Message MUST
> contain at least one audio part, which may be at any location within a
> message and SHOULD be contained in either an audio/wav or audio/basic
> content-type - the only exception being when the originator is aware that
> the recipient can handle other content."
>
> * The current specification says a client SHOULD indicate Critical body
> parts, but MUST non-deliver if cannot render all Critical body parts.
> Hence a client that does not support Critical Content can conform when
> generating IVM messages but not when receiving them. This could either be
> resolved by changing MUST to SHOULD, or by revising the wording to "MUST
> non-deliver the entire message per [CRITICAL] if it supports Criticality".
>
>
> * VPIMv2 support is listed as MAY. This is full support of VPIMv2. The
> goals state we SHOULD support interoperability with VPIMv2. The IVM
> document introduction states that it provides "some level of
> interoperability" with VPIMv2, and later it refers to "partial
> interoperability" (but what we actually specify is full compliance). In
> practice, if the codec is supported and nothing else, there is some level
> of interoperability (but we do not explicitly state this). The current
> language says we ruled "Interoperability out of scope" for the document -
> this could be changed to rule "gatewaying out of scope" to reflect the
> reality today. Our charter includes a separate document on gatewaying
> which has not been addressed (and therefore will not be completed as the
> group is nearly done).
>
> Greg suggested that we should include a discussion of interoperability in
> the document. It could include gatewaying, and discussion of desktops
> which can display VPIMv2 but not process them fully, or can downloading
> plug-ins later providing deferred access to contents. Stuart agreed to
> send a proposal to the list for discussion.
>
> * Security Considerations - currently we just refer to VPIMv2. However
> this does not cover the implications of the ability to include any body
> part type? This could be addressed with a reference to the MIME security
> considerations. Thoughts on other security considerations that should be
> addressed are welcomed (on the list).
>
> * Greg commented that SHOULDs were generally a bad thing and there were
> quite a number of them in the document. Stuart agreed to review them with
> the intention of reducing the number (based on resolutions of the issues
> above).
>
> This document needs to wait for MS-GSM and WAV drafts to be complete for a
> final revision, and then a Working Group last call can be made.
>
> 6.3 Critical Content of Internet Mail (Eric Burger)
>
> - draft-ietf-vpim-cc-04
>
> This document has completed working group last call and has it has gone to
> the Area Directors for review.
>
> 6.4 Message Context for Internet Mail (Eric Burger)
>
> - draft-ietf-vpim-hint-07
>
> This draft went to -07 (due to typo in 06) and has completed working group
> last call and has it has gone to the Area Directors for review.
>
> 6.5 Audio/wav with MS-GSM (Charles Eliot)
>
> - draft-ema-vpim-msgsm-00 (deleted)
> - draft-ema-vpim-wav-00 (deleted)
>
> The drafts have expired (and the WAV has some technical errors). Consensus
> has been reached that we will support both MS-GSM/WAV and G.711 (as
> audio/basic) - so we still need the MS-GSM and WAV documents.
>
> No progress on the documents has been made since San Diego, but this will
> change immediately as Charles has taken it over.
>
> The WAV document needs the technical errors corrected - and a thorough
> rewrite! RFC 2361 already defines IANA Registrations for audio/vnd.wave
> codecs. Microsoft has no issues involving intellectual property around
> RIFF and WAV.
>
> One proposal is to simplify the specification to only include what is
> needed to support IVM, rather than making it a generic definition of WAV.
> However we also need to generate something that is consistent with what is
> already in general use - which may prevent it from being too IVM specific
> (it needs, at least, to be extensible). It can reference existing RFCs and
> documents.
>
> We then need a simple profile for use with IVM, which could be put in the
> IVM document - defining how WAV is used with MS-GSM for IVM.
>
> The MS-GSM draft seem to be technically correct. The current draft
> provides the IANA registration and documents the order/format of GSM
> encoding parameters for MS-GSM. The definition will be for audio/wav not
> audio/ms-gsm to allow as much as possible of the existing deployed base to
> launch the correct application and to play the voice message correctly.
> Which is why this group also needs to be concerned with the broader
> definition of WAV in MIME.
>
> This draft does not describe implementation of a GSM 6.10 codec (this is
> an external document). Given that, Microsoft do not believe that there are
> any IPR issues associated with this draft.
>
> Charles will create the new drafts for review in 3-4 weeks. Once there is
> consensus on those drafts we can update the IVM document and last call it.
>
>
> 7. VPIM Addenda
>
> 7.1 Binary & channel IMAP extensions for VPIM Messages (Lyndon Nerenberg)
>
>
> - draft-nerenberg-imap-binary-04
>
> Binary is pretty much a done deal - one more revision of the draft is
> expected and then it will go in as an individual submission for IETF Last
> Call (around Sept.).
>
> - draft-nerenberg-imap-channel-00
>
> There is a pretty good consensus that the syntax is good. There is still
> work to be done on the semantics of the URIs. This discussion will focus
> on the IMAP-Voice mailing list. Security recommendations are also going to
> be a major piece of work, since a request could invoke the use of
> something like FTP to move the message somewhere outside of the
> authentication realm of the server.
>
> There is also a draft that has been posted to the IMAP Extension list to
> provide access to all the Content-* mime header information for a message.
> Obviously we would like to see Message Context included for VPIM, but it
> may make sense to generalise that further to provide all MIME Header
> information.
>
> 7.2 Calling Line Identification for VPIM Messages (Glenn Parsons)
>
> - draft-ema-vpim-clid-02
>
> This is an existing document that we put to Working Group last call (for
> an extended period as it includes the IETF meeting week).
>
> The draft rules out of scope information providing information beyond what
> you get from the Caller Id. Specifically it rules out of bounds access to
> other, privileged network information.
>
> Should it contain structured data? Previous consensus was that it should
> not. But the context in which the Caller Id information was captured is
> currently lost. Should it be possible to indicate if it is an e.164
> number, or a local PBX number (internal extension), or something else
> (which is probably not algorithmically usable).
>
> Is the SIP Remote Party Id header applicable? No, as that is more for
> system information.
>
> If the originator knows enough about the context to turn it into an
> international number, it should be able to do so. Once you have the full
> e.164 number, or can derive it, how do you indicate that this is what you
> have (e.g. a "+" prefix?). It may be useful to provide both a display name
> (what you got) plus a url specification (from RFC2806). Or the Minimal
> PSTN Address Format (from RFC 2303) could be used. If a url is used, it
> could be allowed to contain either an RFC2806 URI or a mailto containing
> an RFC2303 address.
>
> Greg offered to provide an initial proposal. This issue will be discussed
> further on the list.
>
> 7.3 Voice Messaging Client Behaviour (Glenn Parsons)
>
> - draft-ema-vpim-cb-02
>
> Existing work, based on the Voice Messaging IMAP Client Behaviour work,
> which has been put out to an extended Working Group last call.
>
> 7.4 SIP Message Waiting Indication (Rohan Mahy)
>
> - draft-mahy-sip-message-waiting-02
>
> The SIP group has a draft for MWI using SIP - now a proposed work item for
> the Sipping working group. The XML content format has been removed as
> no-one is using it (could be added back later). Comments from the VPIM
> group are invited. The meeting was positive to the idea of the Sipping
> working group progressing this.
>
> 7.5 SNAP Simple Notification and Alarm Protocol (Noam Shapira)
>
> - draft-shapira-snap-01
>
> SNAP is designed to allow a Notification Server to communicate with an
> E-Mail Server , Voice-Mail server, Calendar server (or whatever), and
> provide notifications to users via MWI, SMS, e-mail, etc. SNAP defines the
> Notification Server to E-Mail/V-Mail server interface. It is intended for
> high volume, high performance applications.
>
> Issues discussed include:
>
> * The fact that it is Push based - there was support in the room for such
> an approach for a highly scalable solution.
>
> * Its Non-Subscription model for high performance - it needs to be
> provisioned by some other needs. There were questions about whether this
> actually gains you anything (if it does, it may well be at start up time
> only), and whether the provisioning oriented model is applicable to many
> real world situations. The author's clearly feel it is.
>
> * The approach of being as informative as possible about the Notification
> state changes to provide maximum functionality (including being sufficient
> to implement current voicemail server behaviour). The syntax was felt to
> be rather fixed . The last draft has added XML as an alternative
> representation, but why have the overhead of 2 ways of doing the same
> thing? But you already need a parser for standard headers and is requiring
> an XML parser reasonable?
>
> The next step is to address security issues and RFC 2822 compliance, and
> add Message Context support.
>
> There was interest in making this a work item of the VPIM working group.
> As the group is looking to wrap up, it would not make sense to add it to
> the charter now. But it the group decides to recharter this could be one
> of the work items they address.
>
> 8. Wrap Up
>
> There was a final discussion of open issues from the Charter not currently
> being addressed:
>
> * IVM-VPIMv2 Interworking - we will look at putting this into the IVM
> draft, if it is not too large;
>
> Content Negotiation - this is somewhat addressed via the LDAP Schema
> draft. There were no objections to dropping further work on this item.
>
> The meeting closed.
>
This archive was generated by hypermail 2.0b3 on Sat Aug 18 2001 - 01:20:10 IDT