Voice Profile for Internet Mail WG (vpim) ========================================= Chairs: John Noerenberg Glenn Parsons Notes by: Stuart McRae Tuesday, August 1, 2000 ======================= Agenda Bashing (Glenn Parsons) ------------------------------- Agenda was reviewed and agreed. Charter review & WG Status (Glenn Parsons) ------------------------------------------ VPIM is now officially a WG. The charter is on IETF Web Site. As as result, many of the drafts has been reset to 00 as their name has changed to include the WG name. The milestones were reviewed - the group is on schedule, apart from the VPIMv2 interworking documentation, and should complete at March meeting next year, as planned. The most likely reason for slippage would be the prerequisite items for VPIMv2 progression. The work topics can be grouped into 3 areas. - VPIMv2 - Internet Voice Mail - VPIM Addenda (applying to VPIMv2 and IVM). Additional information can be found at www.vpim.org. VPIM v2 (Glenn Parsons) ----------------------- * Voice Profile for Internet Mail - version 2 (draft-ietf-vpim-vpimv2r2-00) The process to move to draft standard was reviewed. Ambiguities need to be removed, interoperability testing to be documented, and normative references must all be to be draft standard too (MUST and SHOULD). The normative references (by status) are: Standard: SMTP/MAIL/DNS/etc Draft Standard: Pipelining, MIME Proposed Standard: - Content Duration, multipart/voice-message, audio/32kadpcm These need to also be progressed by this group. - image/tiff The Fax WG is progressing this. - vCard, text/directory These references will be deleted. - DSN/MDN/Enhanced status codes We need to push the appropriate people/groups to progress these. Experimental: Binary - only a MAY, but the author wishes to progress it anyway Informational: TIFF-F ITU-T Standards: E.164, G.726 We will need new versions of all documents (even if there are no changes) in order to get latest boiler plate text. Action: Greg Vaudreuil to work with Keith M to progress DSN & Status Codes. Only corrections/clarification of ambiguities are expected to be needed. This does not need a WG to be chartered - it can be done as individual contributions. Action: John Noerenberg to investigate getting MDN progressed - if the original author does not want to do it, we need to find a volunteer to do so. There will probably be some things that need to be deleted as no-one has implemented them. Documents can go right through the last call before everything else is complete - they will sit in the RFC editors queue until all the prerequisites are done. Substantial editorial changes have been made to improve readability and remove ambiguity in the VPIMv2 specification - e.g. to separate send and reception rules to aid clarity and to clarify behaviour on receipt of unrecognised content types. Other changes include: - NORMAL sensitivity added (for consistency with MIXER) - Direct reference is made to X.400 (instead of via MIXER) - an explicit statement not to use MDN Content-Disposition options - change from "MUST NOT include TO fields if all are not known" to "SHOULD NOT" - reduced spoken reason in MDN from SHOULD to MAY - removed vCards - MAY use headers to create personal address book entry, from SHOULD NOT (as vCard issue goes away) - When relaying SHOULD NOT drop headers, but when gatewaying MAY. The document still needs editorial correction for cut and paste problems, and spelling and formatting errors. * SMTP Service Extensions for Transmission of Large and Binary MIME Messages (draft-vaudreuil-esmtp-binary2-01) This has received a number of implementations (including 3 voicemail systems), so Greg V has revised the documents and put to IESG last call - resulting in a number of comments, so it is undergoing editorial revision during last call. * Interoperability Documentation The VPIMv2 Bake Off is scheduled for 17-19 August, 2000. This will form basis of the implementation document. In parallel with writing this up, the VPIMv2 document will be put into last call. Fax WG update (Claudio Allocchio) --------------------------------- * Minimal GSTN address format in Internet Mail (draft-ietf-fax-minaddr-v2-01) * Minimal FAX address format in Internet Mail ( draft-ietf-fax-faxaddr-v2-01) Claudio reviewed the changes to the Minimal GSTN & Fax Addressing in Internet Mail drafts as part of moving forward to Draft standard. These are minor editorial changes (e.g. to clarify that "GSTN address" means "telephone number"), technical corrections (e.g. it was not accurate to imply that the RHS equates to a specific MTA), and clarifications (e.g. of T.33 Subaddress definition). In addition the appropriate IANA registrations have been included in the document. The plan is to turn the current draft fax interoperability report into a final document, and then issue a last call. Note that RFC 2846 for full addressing has been published (as Proposed), and it defines the IANA registration procedures for service selectors and elements. The VPIM associated selectors can be registered according to this as soon as it is published in a formal specification (presumably an RFC). VPIM Addressing (Glenn Parsons) ------------------------------- * VPIM Addressing (draft-ema-vpim-address-01) This draft clarifies VPIMv2 addressing and defines onramp/offramp address service selectors, intended for routing/address resolution purposes: vpim= I am sending you a VPIM message for this telephone number, you figure out where it should go voice= I want you to deliver the message as an out-dial telephone call to this number amis= Deliver the message to a legacy analogue AMIS compliant voicemail system. The plan to issue this as last call once the Full GSTN Addressing draft is issued (it will probably need slight editorial updates). Q. Could this be used as an indication of primary content? Perhaps, but there was no support for doing so in the room. Q. Is there a default? No, the selector would normally simply not be present - it is only needed if you want to give direction to a gateway. Glenn asked anyone who has implemented an AMIS gateway to check the specification intended for that purpose. IVM (Glenn Parsons, Stuart McRae, Eric Burger) ---------------------------------------------- The goal of this effort is to define a voicemail alternative that behaves more like e-mail (rather than making e-mail behave more like voicemail). It mandates a single codec for compatibility with existing desktops. Backward compatibility with VPIMv2 is optional - but would be a good idea! The new features required are being defined as generic capabilities for e-mail, as they are not generally specific to voicemail. * Goals for Voice Profile for Internet Messaging, Version 3 (draft-ema-vpimv3-goals-01) The authors of this document have both left their employers, so new authors are needed. Some revision is necessary if this is to be published - e.g. the MUSTs, SHOULDs and MAYs should be reviewed and capitalised, consistently with current practice. The opinion was expressed that it needs revision to more explicitly explain the objective of creating voicemail within current e-mail (rather than making e-mail more like voice-mail). There was significant discussion around whether we actually need to publish this document. Is there any point in updating it to indicate what we finally decided to do (after the fact)? Does it have significant historical value? For now, it is worth resubmitting the draft before it expires to keep it around, then we can decide later if we want to publish it permanently as Informational. Action: Emily Candell volunteered to edit the document as needed, in the light of our discussions, and resubmit it to keep it current. If anyone has comments to be incorporated in the revision, please send them to the list. * Internet Voice Messaging (draft-ietf-vpim-ivm-00) This document represents a merging of the previous simple VPIMv3 draft from Glenn Parsons and the Internet Voice Messaging draft by Stuart McRae (with joint authorship). The presentation of the draft had been updated to account for revisions to Critical Content (nor Content Hint) and Primary Content since the draft was issued (these changes will be incorporated into the next draft). The draft is called Internet Voice Message (rather than Internet Voice Mail), as what it defines is called a "voicemail message". The IMAP references have been removed (per earlier discussion). Steve Hole offered to take some of the open IMAP actions and move them forward in conjunction with the IETF IMAP community. The general philosophy adopted is that the items required for compatibility with the installed base of e-mail clients are MUST, the items which add value specific to voicemail are SHOULD, and the items which focus on interoperability with VPIMv2 are MAY. This provided a starting point from which the relative importance of different attributes can be discussed. In all probability the draft ought to be updated to make inclusion of a Primary Content a MUST instead of a SHOULD - because its presence is the defining characteristic that makes something an Internet voice message. Q. Is the reference to MUST use multipart/report necessary - that is what requiring DSNs implies? On the other hand past experience has made it clear that stating things explicitly is a good thing. Therefore this statement should be clarified to explain why it is required (specifically to allow a TUI to indicate a deliver failure, where it could not interpret some nonstandard form of non delivery notification). The draft requires use of audio/wav content encoded using the Microsoft GSM codec. There was support for retaining the table of Codec requirements in the draft. Q. Can the spoken name be specified for more than one recipient? No, the syntax doesn't support it - VPIMv2 allows spoken recipient only if there is only one recipient (although the "binary headers" proposal could support this). This should be clarified in the draft. Possible security issues discussed included: How to handle SPAM (same as e-mail), exposure because of numeric addresses (IVM does not require numeric addresses 0 this is a VPIMv2 issue and should be discussed in the addressing spec. - Greg Vaudreuil to discuss with Glenn); is there existing IETF e-mail SPAM work we should reference? * Partial Non-Delivery Notification (draft-ema-vpim-pndn-01) The only change since Adelaide is to remove two alternative formats of PNDN so as to avoid causing processing problems for existing systems. Q. Is automatic processing of DSNs actually done (rather than just displaying the text)? Yes, voicemail systems like to process them so they can voice the content, and list servers like to get them to unsubscribe invalid recipients, but it is not clear that clients are supporting them. * Critical Content of Internet Mail (draft-ietf-vpim-cc-00) In traditional e-mail, either a message is delivered or not. With systems of lesser capability (e.g. SMS gateways or voicemail systems that cannot store text) then some parts of the message may not be deliverable. Some of these body parts matter to the sender and some do not. E.g. a user would not care if you could not deliver the "spinning earth" icon Notes can send or the TNEF attachment Exchange sends, as the user never even knew they were sending them. This mechanism defined a method of identifying the critical parts of a message, indicating that the originator wants the message to fail if they cannot be delivered, and also important parts where the originator would like to know if they cannot be delivered - as well as the parts the originator does not care about. This allows the handling of recipient systems with lesser capability than the sender. If a relay, gateway or user agent cannot relay, deliver or render any of the CRITICAL body parts, the entire message fails. If all of the critical parts can be processed, then the message is delivered. If a body part marked IMPORTANT cannot be processed, then a notification will be returned (either a Delivery Status Notification, via a PNDN, or a Message Disposition Notification, via a mechanism still to be defined), but the message should not be rejected. If the sender doesn't care about some content (marked IGNORE), then they don't want any notifications. It is important to note that DSNs are gatewayable (e.g. under MIXER) so the design must take account of this. Backward compatibility is also clearly a critical requirement. There was a strong opinion in the room that IMPORTANT was a problem. If a gateway drops content it would need to return a partial relay DSN (which puts useful content in a relay DSN, which is not normally expected to contain any). If a user accesses a Unified Messaging system from a device that cannot access all content types, they can probably subsequently access it from a different device that can - Unified Messaging solutions are expected to be able to handle all content types. Therefore this concept is primarily useful for voicemail servers which cannot handle all content types - but they will probably be using VPIMv2 instead of IVM. Is "important" important? The consensus in the room was to drop IMPORTANT - this discussion will be taken to the list. This implies that PNDN is not needed and PMDN need not be defined. The definition of a new header fields causes IMAP issues as there is no way to get hold of the whole MIME structure with all content headers in one go - you have to ask for them for each body part, and most clients don't do that. This would be a reason to use a parameter on Content-Disposition rather than adding a new header. This was noted to be an issue for Content-Duration in VPIMv2 as well (Greg to review). Critical content within a contained RFC822 message is ignored - it is the criticality of the outer most body part that matters. If this becomes a binary value, the issue of what happens if the recipient does not recognise the value of the attribute probably goes away - since it can only be one of the two values. THURSDAY, August 3, 2000: 1530-1730 =================================== Agenda Re-Bashing (Glenn Parsons) --------------------------------- The agenda was reordered to fit with various presenters travel arrangements. SIP WG update (Rohan Mahy) -------------------------- * SIP Extensions for Message Waiting Indication (draft-mahy-sip-message-waiting-00) Rohan Mahy discussed his draft on how to get message waiting information using SIP. SIP provides a way to initiate sessions with users, who may be mobile, via a series of "contacts" for the user, identified by URIs (e.g. a cell-phone, a voicemail system, etc.) The need for MWI services for SIP was reviewed - this is accepted as one of many presence services that SIP needs. There doesn't seem to be an existing protocol that it would be appropriate to use. In addition, it seems like a better job can be done than the traditional boolean MWI (e.g. "you have 3 new messages, 1 urgent"). There is a mechanism already for notifications within SIP (subscribe/notify) and there is already a proposal to use this for Instant Messaging presence in the IMPP WG. Under the draft you can subscribe to message-summary events for a period of time, or just request a snapshot. It supports both simple text and XML format responses. The simple text is not meant to be user consumable - it still needs to the parsed. The XML version provides more sophisticated capabilities designed for IMAP servers (such as multiple mail folders) and can be processed via an XSL. Rohan is looking for feedback on whether both formats are needed, and what content is really useful. The feedback in the meeting was that if parsing is needed, then you only want one format, and XML is the right one. If you subscribe to one mailbox from multiple devices, once the message changes state (e.g. is read) all subscribers would receive an updated notification. Defining the concept of the number of messages in a specific class requires some way to characterise messages, and then classify them based on that and the various IMAP flags. How to do this summarisation is an issue. Should it be defined in the standard? Should it be decided by the server implementor? Should there be a language to allow the client to define how to do it? Should the flags for all messages simply be pushed to the client? This draft will be raised as a discussion topic on the VPIM list. ENUM WG update (Richard Shockey) -------------------------------- * ENUM Service Specific Provisioning: Principles of Operation (draft-ietf-enum-operation-01) * E.164 number and DNS (draft-ietf-enum-e164-dns-02) The ENUM problem statement is: how do callers find services on the Internet if you only have a telephone number, and how do subscribers define their preferences for incoming calls. The solution is to put phone numbers into the global DNS systems. It uses DNS Naming Authority Pointer (NAPTR) records to find IP addresses, SIP/H.323 addresses, mail addresses, VPIM addressed, etc. The IAB has defined ".e164.arpa" as a highly structured domain for the resolution of telephone numbers. The e.164 (full international) telephone number is added in reverse order for the lookup (e.g. +1 412 565 6008 becomes 8.0.0.6.5.6.5.2.1.4.1.e164.arpa). The group expects a three level resolution model: from the root of e164.arpa there is delegation to National (country code) DNS servers, which delegate further to Service Provider DNS servers, which can optionally use a service specific LDAP server for the actual lookup (which is where the VPIM host name might be stored). Identification of the national delegation server occurs using the country code digits (e.g. "4.4.e164.arpa" is the UK and "1.e164.arpa" is the US). After resolution of the full telephone number the DNS server then returns a list of URLs (e.g. a SIP address, an SMTP address and a VPIM address) that are defined for that telephone number, in order of the users preferred contact method. The option of returning a reference to an LDAP directory would provide access to things like Spoken Name, which could be stored in a directory but not in the DNS. The current status is that rough consensus on the core protocol and requirements document has been achieved, and an operations document is underway. The organisation of trials for the protocol are currently under study. Delegation and validation issues were rendered out of scope for the WG, but are going to need to be addressed at some point. The way national delegation servers get defined and how IANA gets told to point to those servers, are still under consideration. However a short term testing system can probably be established before all these issues get resolved. The critical thing is to ensure sufficient integration with the existing PSTN numbers, to prevent "slamming" and "highjacking", which is going to require a tight link between the people issuing the telephone numbers and the people managing the servers (also needed to ensure a number is deleted from the DNS when it is deleted from the telephone network). VPIM Directory (Greg Vaudreuil) ------------------------------- * Voice Message Routing Service (draft-ietf-vpim-routing-00) This draft builds on ENUM to define its use with VPIM when a mailto url is not available in the DNS entry. It provides two modes of operation, one when there is an LDAP VPIM directory available (in which case it returns the URI of the LDAP server), and the other when there is not (or, if it exists, it cannot be reached from the originator). This addresses the case where you have a client, you have an e-mail system, but that is all you have and you need to send mail - what do I do?. The solution must be algorithmic, so the idea is to get the mail to a directory enabled inbound mail gateway which can resolve the number. First you build a domain name (RHS) via enum with a service selector ("_vpim.") at the front, then you put the telephone number on the LHS and send it, e.g.: +14125656008@_vpim.8.0.0.6.5.6.5.2.1.4.1.e164.arpa With appropriate MX records in the DNS, this can get routed to a server which is then able to look up the telephone number and identify the destination mailbox address. Action: Greg Vaudreuil to add a discussion of the mailto url to the document Action: Patrick Fältström to send his thoughts on this draft to the list * Voice Messaging Directory Service (draft-ietf-vpim-vpimdir-00) This is a merge of the schema documents from Anne Brown and Greg into a single proposal. This uses the enum capabilities to remove the need to create a tree in the directory which indexes the entry digit by digit. The discussion of the attributes defined in the document was deferred to the mailing list. Action: Greg Vaudreuil to summarise the issues with the documents for the list. Directory Service (Dave Peek) ----------------------------- * Internet-Telephony Directory for Mapping E.164 to Internet Addresses (draft-peek-enum-itd-00) Dave described the Global Internet Telephony Directory deployed by NetNumber, which is very similar to enum in the way it turns telephone numbers into Internet information. This was done to enable a number of services: - "Simply Reply" to messages from outside callers - "All in one mailbox" by linking the wireless and wireline mailboxes from different Service Providers - "Global messaging" using VPIM between private and public networks (for "intentional messaging") - "Spoken name" to confirm the recipient identity prior to sending - "IP-PBX Locating" of servers and end points for calls between IP enabled PBXs, Centrexes and ACDs - "IP-Fax/IP-Print" location of end points. Discussion is currently underway on the business models and how people will make money providing some of these services, which is encouraged by the appearance of more outsourced directory providers. The VMA (Voice Messaging Association) and EMA are focussing on the business aspects of these sorts of capability. IVM Continued (Eric Burger, Glenn Parsons) ------------------------------------------ Discussion between the two meetings by the IMAP WG members present led to a feeling that IMAP restrictions should not be forcing us to overload Content-Disposition, and it is probably more appropriate to define a new tag for Criticality and then figure out how to deal with this in IMAP. The counter view was that this could create an issue if the client wants to use this feature but the server doesn't support it. However, the IMAP experts felt that this is just the start of a number of similar issues elsewhere which need to be addressed properly. This topic clearly needs more discussion on the mailing lists. Action Steve Hole to raise the issue on the VPIM List and copy the IMAP list. Clarification: The chair emphasised that we had proposed the deletion of IMPORTANT in Critical Content, and so we no longer need PNDNs for this purpose, but that no consideration had yet been given to whether we still progress Partial Delivery Notifications (and develop Partial Message Disposition Notifications) anyway. * Primary Content of Internet Mail (draft-burger-vpim-pc-00) This draft has been revised and reissued as the Content Hint draft (draft-ietf-vpim-hint-00), incorporating work by Charles Eliot and Graham Klyne. This is intended to provide an infrastructure to classify messages in order to allow UAs to respond to the user expectations of the behaviour of systems for different types of message. The concept of user expectations as to how a specific message will be processed was noted as being critical to understanding the intent of this feature. One fundamental requirement of this specification is that if a message is incorrectly labelled, that must not prevent it from being correctly processed. The sorts of things you could use it for include: how to present the message to the recipient, how to handle delivery, what icons to put in the list of e-mails, etc. Auto-detection is not sufficient - just because a message is an image it doesn't mean it is a fax, just because it is WAV file does not necessarily mean it is voicemail, and if you get a music file as WAV attachment with the album cover as an image and the lyrics as text - what type is that? The sender is the one who knows what he thinks he is sending, and this field is a way of sending that information with the message so the recipient has the option of using this information to change the way they handle the message. There is no other way a receiving UA can tell the difference between a WAV file that is a song track and a WAV file that is a voicemail message. So, this draft is designed to let you identify messages as belonging to one of a small number of enumerated (registered) message classes. The level of difficulty that should be associated with adding new values was discussed extensively, as well as the question of whether structuring is needed (e.g. to classify business voicemail and private voicemail) - this was identified as a complex question that needs more discussion on the list. It was commented that as an RFC822 header, this should not start "Content-", since this prefix has been taken by MIME (Message-Hint was mentioned as a possible alternative). The initial set of values proposed were: voice-message, fax-message, video-message, sms-message (it was suggested that this should it be short-message, to embrace pager messages as well), none (i.e. when it is not present, this implies e-mail) and X-mumble (user defined). * audio/wav with MS-GSM codec (draft-ema-vpim-wav-00 & draft-ema-vpim-msgsm-00 - deleted) WG members were warned that if you they are going to implement to these specifications, take care as they contain errors. The authors still want to progress this work. They don't expect to have a problem with WAV, but they are still working on issues around MS-GSM. The issue was raised of whether we wait for Microsoft here, or reopen the discussion on alternatives - e.g. audio/basic (G.711), which is much bigger but also pretty much available everywhere. There was consensus that if went to an alternative, that is where we would go. Therefore there is hopefully no need to reopen the discussion until the Microsoft position becomes clear, or the deadlines come closer. Fax, CONNEG & RESCAP WGs update (Graham Klyne) ---------------------------------------------- * MIME content types in media feature expressions (draft-ietf-conneg-feature-type-03) Conneg is nearly done. When the 3 drafts in the RFC editors queue are out, the group will close. The revised feature schema for fax is awaiting publication, as is document providing a mapping between T.30 frames and media feature expressions (as a concrete example of the application of media feature expressions). * Full Fax Mode (FFPIM) (draft-ietf-fax-ffpim-01 - deleted) This is the logical next step after simple and extended mode of fax in capturing the user experience of fax. Full Mode tries to get as close as possible within the current limitations of the Internet mail environment. The first area covered is content negotiation (which could also be applicable to VPIM), which allows a recipient to request an alternative form of a message it received. The second extends the Deliver By specification (RFC 2852) to provide timely delivery for Internet Fax in order to let a user know that a fax cannot be delivered quickly (i.e. with the intent of creating determinism for the sender rather than accelerating delivery). The fax WG is also looking an co-sponsoring the Partial Delivery Notification work. It is needed to respond to a formal request from the ITU to provide information on which components of a fax can be delivered. Action: Fax WG chair to take this discussion to the VPIM and FAX lists. * RESCAP Scenarios (draft-ietf-rescap-scenarios-00) There is also an effort to get RESCAP moving again, and to get something out that people can start to play with and find how useful it is. VPIM Addenda (Glenn Parsons) ---------------------------- * Voice Messaging IMAP Client Behaviour (draft-ema-vpim-cb-00) This draft looks at how a client might use the "content hint" (it is on the www.vpim.org site but not yet an Internet draft). It is intended to be loose guidelines of what is desirable rather than a specification of what is to be done. Suggestions include: - Message Icon selection - Display Senders Telephone Number rather than FROM field content - Display message size in seconds or pages not Kilobytes - Provide a view of the message in voice mail or fax style - Mark the message ready when the voice part is played not when the text is displayed Action: Glenn Parsons send this list to the list for discussion Comment: This "content hint" concept is really a descriptive tag about how the message was created/sent, rather than a hint about what to do with it. The document also defines IMAP client extensions to support voicemail, which, it was suggested, should be split out into a separate document (to be progressed in consultation with the IMAPEXT working group). * SMTP Service Extensions for Transmission of Large and Binary Message Headers (draft-vaudreuil-binaryheaders-00) This proposal puts spoken name in the headers - WG members are requested to read it and comment on the list. * Calling Line Identification for VPIM Messages (draft-ema-vpim-clid-00) This proposal stores the caller name and number for an answered call in an RFC 822 header field (instead of forcing it into the descriptive part of a fake e-mail address, when there isn't really a reply address). The author is going to also add a way to store some of the additional information provided by the telephone system - this will be discussed on the list. Q. Is this really envelope data or content data? It is header data. Q. Wouldn't it might be useful to put it in a visible body part in case the UA hides extra header data, anyway. But then a UA would need to retrieve the content before it could display this information in the list of outstanding messages. These alternatives need to be discussed in more detail on the list. Action: Attendees to review the draft and take up the discussion on the list. Work Group Focus - Glenn Parsons -------------------------------- To close, Glenn reiterated the Work Groups focus areas: 1. Progress VPIMv2 to draft 2. IVM 3. The VPIM addenda items including: addressing, directory, IMAP, content negotiation Everyone was encouraged people to contribute more comment on the list, which tends to see less discussion than occurs at the meetings.