---------- From: Pete Resnick Sent: Monday, March 29, 1999 1:57 am To: Parsons, Glenn [NORSE:6L45-I:EXCH] Cc: 'vpim-l@ema.org' Subject: RE: IETF VPIM BOF Draft Minutes On 3/29/99 at 12:35 AM -0500, Glenn Parsons wrote: >>2. Paragraphs 3 and 4 are fluff. Sentences that begin "The EMA has >>established VPIM conformance procedures that will provide customer >>confidence" send up red flags for me. Mention of interoperability >>testing for the purposes of moving v2 to Draft Standard are >>appropriate; mention of the same for puposes of "major service >>providers" who want to "deploy compliant products" is not. > >I'm afraid I don't understand your concern. Why the red flags? Is >it the wording, talking about interoperability testing, saying that >vendors have implemented VPIM, or saying that people are deploying >it? As I said, talking about interoperability testing is fine, so long as it is in the context of IETF work. Talking about customer confidence has nothing whatsoever to do with IETF work, nor does whether vendors are "committed" to deploying, nor does service providers being "interested". As someone interested in reading the minutes of an IETF BOF session, I am interested in (a) what work is proposed to be done in the IETF; (b) what benefit there will be to doing this work in the IETF; and (c) what I need to do to participate in doing IETF work in this area. The state of interoperability testing for purposes of moving to draft standard *is* an answer to one of those issues. What's going on in the marketing of VPIM to vendors and service providers does not address these issues at all and does not belong in the minutes. (Personally, I would have preferred if it didn't happen in the BOF meeting as well.) Let's stick to engineering. >Yes, suggestion is the wrong word. I'll find a better word (unless >you have a suggestion :-). I'm all for "argument" or "opposition". Sugar coating is not necessary. We're all grownups. I don't think anyone's going to be offended by such words. :-) >As for the consensus being against the approach of the UM document >-- I'll have to disagree with that. I noted several people speaking >in favour of the proposal (as well as several against). My >assessment is there is no consensus yet and that further discussion >is >required -- like what we started over lunch. It is this current >lack of consensus that necessitates creating an IETF working group. I'll agree to that assessment, at least for the time being. Certainly I'm human and my ears are at least a little more attuned to the people who agree with my position than those who disagree. :-) But I think we do agree that there's no consensus at the moment for the current proposal is the right one. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102 ---------- From: Graham Klyne Sent: Monday, March 29, 1999 9:25 am To: Pete Resnick Cc: 'vpim-l@ema.org' Subject: multipart/voice-message and other ideas At 23:57 28/03/99 -0600, Pete Resnick wrote: >But I >think we do agree that there's no consensus at the moment for the >current proposal is the right one. I think this is a fair position. As one who's reviewed the drafts, and not found any fundamental problem with the approach, I'd like to see the perceived problems and alternative suggestions aired on this list. For myself: I think a different multipart to /mixed is required. This is because there are additional handling semantics (the so-called "discard rules") that are not appropriate to voice messages, etc. I am not convonced that multipart/related is appropriate for the same reason, but I'm not fully conversant with /related issues so I am open to comments. An issue not yet fully addressed in this group is that a message (as opposed to a document) may have some additional content-based semantics. For example, cover pages, as currently under discussion in the fax WG. The current VPIM framework does provide a hook that can be used to incorporate such semantics. I would prefer the solution framework to be reasonably media-agnostic. I would suggest an approach along the lines of: (1) a single multipart type for message content (multipart/message?), with a parameter to indicate primary media content. The main purpose of this is to (a) signal the possible presence of message-related semantics in the body, and (b) to allow dispatching to an appropriate device or application for presentation -- e.g. telephone vs fax machine vs desktop computer. (2) use of a content-disposition within the message content to indicate primary vs non-primary content (e.g. ). I note this is not very different to the current VPIM proposals. #g ------------ Graham Klyne (GK@ACM.ORG) ---------- From: Pete Resnick Sent: Monday, March 29, 1999 1:57 am To: Parsons, Glenn [NORSE:6L45-I:EXCH] Cc: 'vpim-l@ema.org' Subject: RE: IETF VPIM BOF Draft Minutes On 3/29/99 at 12:35 AM -0500, Glenn Parsons wrote: >>2. Paragraphs 3 and 4 are fluff. Sentences that begin "The EMA has >>established VPIM conformance procedures that will provide customer >>confidence" send up red flags for me. Mention of interoperability >>testing for the purposes of moving v2 to Draft Standard are >>appropriate; mention of the same for puposes of "major service >>providers" who want to "deploy compliant products" is not. > >I'm afraid I don't understand your concern. Why the red flags? Is >it the wording, talking about interoperability testing, saying that >vendors have implemented VPIM, or saying that people are deploying >it? As I said, talking about interoperability testing is fine, so long as it is in the context of IETF work. Talking about customer confidence has nothing whatsoever to do with IETF work, nor does whether vendors are "committed" to deploying, nor does service providers being "interested". As someone interested in reading the minutes of an IETF BOF session, I am interested in (a) what work is proposed to be done in the IETF; (b) what benefit there will be to doing this work in the IETF; and (c) what I need to do to participate in doing IETF work in this area. The state of interoperability testing for purposes of moving to draft standard *is* an answer to one of those issues. What's going on in the marketing of VPIM to vendors and service providers does not address these issues at all and does not belong in the minutes. (Personally, I would have preferred if it didn't happen in the BOF meeting as well.) Let's stick to engineering. >Yes, suggestion is the wrong word. I'll find a better word (unless >you have a suggestion :-). I'm all for "argument" or "opposition". Sugar coating is not necessary. We're all grownups. I don't think anyone's going to be offended by such words. :-) >As for the consensus being against the approach of the UM document >-- I'll have to disagree with that. I noted several people speaking >in favour of the proposal (as well as several against). My >assessment is there is no consensus yet and that further discussion >is >required -- like what we started over lunch. It is this current >lack of consensus that necessitates creating an IETF working group. I'll agree to that assessment, at least for the time being. Certainly I'm human and my ears are at least a little more attuned to the people who agree with my position than those who disagree. :-) But I think we do agree that there's no consensus at the moment for the current proposal is the right one. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102 ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Monday, March 29, 1999 1:35 am To: 'Pete Resnick' Cc: 'vpim-l@ema.org' Subject: RE: IETF VPIM BOF Draft Minutes Pete, > A few comments. Let's try to keep in mind that these are to appear in > the minutes of an engineering meeting, not a marketing presentation. > > 1. After "An historical background and overview of VPIM was > presented.", strike the rest of the paragraph. No need for this in > the minutes. At most, list the references to AMIS-D, RFC 1911, and > RFC 2421. Engineers are good at looking up references > I didn't think it was too fluffy -- it is just a background summary of what was presented at the start of the meeting. Still, I can thin it out a bit. > 2. Paragraphs 3 and 4 are fluff. Sentences that begin "The EMA has > established VPIM conformance procedures that will provide customer > confidence" send up red flags for me. Mention of interoperability > testing for the purposes of moving v2 to Draft Standard are > appropriate; mention of the same for puposes of "major service > providers" who want to "deploy compliant products" is not. > I'm afraid I don't understand your concern. Why the red flags? Is it the wording, talking about interoperability testing, saying that vendors have implemented VPIM, or saying that people are deploying it? > 3. The use of the word "suggestion" throughout seems a little > unrepresentative of the discussion. For example (to point to one of > my own "suggestions"), the discussion of the Unified Messaging > document says, "Suggestions were made that the same results can be > achieved using multipart/related and marking the most > important/primary body using the start tag." It didn't seem like > these were suggestions at all. Perhaps a better way to put it would > be, "There were strong feelings that the the approach of using a > specific subtype of multipart for each primary type was the wrong way > to go and that other existing mechanims were more appropriate." Or > perhaps, "There was strong argument in the room that...". Heck, if > this were already a working group, I'd say there was some pretty > strong consensus in the room *against* the approach in that document. > Yes, suggestion is the wrong word. I'll find a better word (unless you have a suggestion :-). As for the consensus being against the approach of the UM document -- I'll have to disagree with that. I noted several people speaking in favour of the proposal (as well as several against). My assessment is there is no consensus yet and that further discussion is required -- like what we started over lunch. It is this current lack of consensus that necessitates creating an IETF working group. Thanks for your comments. Cheers, Glenn. ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Monday, March 29, 1999 1:35 am To: 'Pete Resnick' Cc: 'vpim-l@ema.org' Subject: RE: IETF VPIM BOF Draft Minutes Pete, A few comments. Let's try to keep in mind that these are to appear in the minutes of an engineering meeting, not a marketing presentation. 1. After "An historical background and overview of VPIM was presented.", strike the rest of the paragraph. No need for this in the minutes. At most, list the references to AMIS-D, RFC 1911, and RFC 2421. Engineers are good at looking up references I didn't think it was too fluffy -- it is just a background summary of what was presented at the start of the meeting. Still, I can thin it out a bit. 2. Paragraphs 3 and 4 are fluff. Sentences that begin "The EMA has established VPIM conformance procedures that will provide customer confidence" send up red flags for me. Mention of interoperability testing for the purposes of moving v2 to Draft Standard are appropriate; mention of the same for puposes of "major service providers" who want to "deploy compliant products" is not. I'm afraid I don't understand your concern. Why the red flags? Is it the wording, talking about interoperability testing, saying that vendors have implemented VPIM, or saying that people are deploying it? 3. The use of the word "suggestion" throughout seems a little unrepresentative of the discussion. For example (to point to one of my own "suggestions"), the discussion of the Unified Messaging document says, "Suggestions were made that the same results can be achieved using multipart/related and marking the most important/primary body using the start tag." It didn't seem like these were suggestions at all. Perhaps a better way to put it would be, "There were strong feelings that the the approach of using a specific subtype of multipart for each primary type was the wrong way to go and that other existing mechanims were more appropriate." Or perhaps, "There was strong argument in the room that...". Heck, if this were already a working group, I'd say there was some pretty strong consensus in the room *against* the approach in that document. Yes, suggestion is the wrong word. I'll find a better word (unless you have a suggestion :-). As for the consensus being against the approach of the UM document -- I'll have to disagree with that. I noted several people speaking in favour of the proposal (as well as several against). My assessment is there is no consensus yet and that further discussion is required -- like what we started over lunch. It is this current lack of consensus that necessitates creating an IETF working group. Thanks for your comments. Cheers, Glenn. ---------- From: Pete Resnick Sent: Sunday, March 28, 1999 7:57 pm To: Parsons, Glenn [NORSE:6L45-I:EXCH] Cc: 'vpim-l@ema.org' Subject: Re: IETF VPIM BOF Draft Minutes On 3/28/99 at 5:53 PM -0500, Glenn Parsons wrote: >I will need to submit these minutes to the IETF, please review them >and let me know if you have any comments. I will send them in >(along with the slides presented) next Monday (aka Easter). A few comments. Let's try to keep in mind that these are to appear in the minutes of an engineering meeting, not a marketing presentation. 1. After "An historical background and overview of VPIM was presented.", strike the rest of the paragraph. No need for this in the minutes. At most, list the references to AMIS-D, RFC 1911, and RFC 2421. Engineers are good at looking up references 2. Paragraphs 3 and 4 are fluff. Sentences that begin "The EMA has established VPIM conformance procedures that will provide customer confidence" send up red flags for me. Mention of interoperability testing for the purposes of moving v2 to Draft Standard are appropriate; mention of the same for puposes of "major service providers" who want to "deploy compliant products" is not. 3. The use of the word "suggestion" throughout seems a little unrepresentative of the discussion. For example (to point to one of my own "suggestions"), the discussion of the Unified Messaging document says, "Suggestions were made that the same results can be achieved using multipart/related and marking the most important/primary body using the start tag." It didn't seem like these were suggestions at all. Perhaps a better way to put it would be, "There were strong feelings that the the approach of using a specific subtype of multipart for each primary type was the wrong way to go and that other existing mechanims were more appropriate." Or perhaps, "There was strong argument in the room that...". Heck, if this were already a working group, I'd say there was some pretty strong consensus in the room *against* the approach in that document. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102 ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Sunday, March 28, 1999 6:53 pm To: 'vpim-l@ema.org' Subject: IETF VPIM BOF Draft Minutes <> Folks, Attached are the minutes from the VPIM BOF at IETF. We had a very strong attendance and I look forward to our continuing success! I will need to submit these minutes to the IETF, please review them and let me know if you have any comments. I will send them in (along with the slides presented) next Monday (aka Easter). <> BTW, this is all on the web page if you can't decode my message :-) Cheers, Glenn. PS. We'll also review the minutes at the EMA VPIM meeting this Monday. ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Sunday, March 28, 1999 6:53 pm To: 'vpim-l@ema.org' Subject: IETF VPIM BOF Draft Minutes Folks, Attached are the minutes from the VPIM BOF at IETF. We had a very strong attendance and I look forward to our continuing success! I will need to submit these minutes to the IETF, please review them and let me know if you have any comments. I will send them in (along with the slides presented) next Monday (aka Easter). <> BTW, this is all on the web page if you can't decode my message :-) Cheers, Glenn. PS. We'll also review the minutes at the EMA VPIM meeting this Monday. ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Friday, March 26, 1999 11:27 am To: vpim-l@ema.org Subject: RE: EMA VPIM Meeting Folks, As clarification Dallas is on Central time, so the meeting time is 8am - 12noon CST. See you there, Glenn. > ---------- > From: Parsons, Glenn [NORSE:6L45-I:EXCH] > Sent: Thursday, March 25, 1999 3:00 PM > To: vpim-l@ema.org > Subject: EMA VPIM Meeting > > Folks, > > As most of you know, the annual EMA conference is next week. The Voice > Messaging Committee will be meeting on Monday, March 29th from 8am to 12 > noon. The meeting will focus on various topics. > > The proposed agenda is: > > > - Introductions & Summary of work > > - VPIM v2 Interoperability testing status > > - VPIM v2 deployment status (eg, VMA Helsinki) > - Summary of IETF VPIM BOF > > - VPIM Addressing > - IMAP extensions for VPIM > > - VPIM v3 > - codecs > - primary content > - discard rules > - content negotiation > > I would suspect that the majority of the time will be spent on discussing > VPIMv3. > > For those of you who cannot make it to Dallas and are interested in the > discussions, I would encourage you to join us via teleconference. The > bridge we have set up is: > > > Bridge: 972-685-6338 > > Passcode: 789742# > > > Cheers, > Glenn. > ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Friday, March 26, 1999 11:27 am To: vpim-l@ema.org Subject: RE: EMA VPIM Meeting Folks, As clarification Dallas is on Central time, so the meeting time is 8am - 12noon CST. See you there, Glenn. ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Thursday, March 25, 1999 3:00 PM To: vpim-l@ema.org Subject: EMA VPIM Meeting Folks, As most of you know, the annual EMA conference is next week. The Voice Messaging Committee will be meeting on Monday, March 29th from 8am to 12 noon. The meeting will focus on various topics. The proposed agenda is: > - Introductions & Summary of work > - VPIM v2 Interoperability testing status > - VPIM v2 deployment status (eg, VMA Helsinki) - Summary of IETF VPIM BOF > - VPIM Addressing - IMAP extensions for VPIM > - VPIM v3 - codecs - primary content - discard rules - content negotiation I would suspect that the majority of the time will be spent on discussing VPIMv3. For those of you who cannot make it to Dallas and are interested in the discussions, I would encourage you to join us via teleconference. The bridge we have set up is: > Bridge: 972-685-6338 > Passcode: 789742# > Cheers, Glenn. ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Thursday, March 25, 1999 11:00 am To: vpim-l@ema.org Subject: EMA VPIM Meeting Folks, As most of you know, the annual EMA conference is next week. The Voice Messaging Committee will be meeting on Monday, March 29th from 8am to 12 noon. The meeting will focus on various topics. The proposed agenda is: > - Introductions & Summary of work > - VPIM v2 Interoperability testing status > - VPIM v2 deployment status (eg, VMA Helsinki) - Summary of IETF VPIM BOF > - VPIM Addressing - IMAP extensions for VPIM > - VPIM v3 - codecs - primary content - discard rules - content negotiation I would suspect that the majority of the time will be spent on discussing VPIMv3. For those of you who cannot make it to Dallas and are interested in the discussions, I would encourage you to join us via teleconference. The bridge we have set up is: > Bridge: 972-685-6338 > Passcode: 789742# > Cheers, Glenn. ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Thursday, March 25, 1999 5:53 am To: vpim-l@ema.org Subject: EMA VPIM Meeting Folks, As most of you know, the annual EMA conference is next week. The Voice Messaging Committee will be meeting on Monday, March 29th from 8am to 12 noon. The meeting will focus on various topics. The proposed agenda is: - Introductions & Summary of work - VPIM v2 Interoperability testing status - VPIM v2 deployment status (eg, VMA Helsinki) - Summary of IETF VPIM BOF - VPIM Addressing - IMAP extensions for VPIM - VPIM v3 - codecs - primary content - discard rules - content negotiation I would suspect that the majority of the time will be spent on discussing VPIMv3. For those of you who cannot make it to Dallas and are interested in the discussions, I would encourage you to join us via teleconference. The bridge we have set up is: Bridge: 972-685-6338 Passcode: 789742# Cheers, Glenn. ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Wednesday, March 17, 1999 5:48 pm To: vpim-l Subject: RE: multipart/voice-message, /fax-message > I aso have a question regarding that framework: is it intended that ALL > parts with the indicated primary media type must be delivered, or just the > "main" one(s) (e.g. those marked with content-disposition:attachment might > be discarded)? > > The intent is that if it is primarily a voice message, than all the audio/* parts are part of the primary media type and must not be discarded if the message is noted as delivered. Note that VPIMv2 states that all audio attachments should be content-disposition:inline so that they are not presented as attachments. Glenn. ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Wednesday, March 17, 1999 10:47 am To: vpim-l Subject: RE: multipart/voice-message, /fax-message I aso have a question regarding that framework: is it intended that ALL parts with the indicated primary media type must be delivered, or just the "main" one(s) (e.g. those marked with content-disposition:attachment might be discarded)? The intent is that if it is primarily a voice message, than all the audio/* parts are part of the primary media type and must not be discarded if the message is noted as delivered. Note that VPIMv2 states that all audio attachments should be content-disposition:inline so that they are not presented as attachments. Glenn. ---------- From: Graham Klyne Sent: Tuesday, March 16, 1999 7:17 pm To: vpim-l Subject: multipart/voice-message, /fax-message All, Following suggestions today at the IETF VPIM BOF, I have briefly reviewed the multipart/related work and feel that, while it could be coerced to create a framework for unified messaging along the lines of , I am not convinced it is the most appropriate means to do so. However, I do think that a single multipart/... type with a primary media type parameter would be a good way to proceed. As I understand it, the intention is: (a) to establish the primary media type for a message, and (b) to establish appropriate "discard rules": a framework for indicating that some parts of a message are not ancillary rather than central to the message content. There is a third feature that I think would be a useful part of this framework: to establish an environment for including message metadata: this idea is illustrated by Mike Ruhl's fax cover page draft . I feel that the implied semantics that part of the message content may be disregarded is something absent from multipart/related, and tpo introduce such semantics into the context of an existing structure might be harmful. I aso have a question regarding that framework: is it intended that ALL parts with the indicated primary media type must be delivered, or just the "main" one(s) (e.g. those marked with content-disposition:attachment might be discarded)? #g ------------ Graham Klyne (GK@ACM.ORG) ---------- From: wjyang@mjl.co.kr Sent: Tuesday, March 16, 1999 5:35 am To: vpim-l Subject: About Conformance Tesing VPIM v3. Dear. We are South Korean Telecommunication Company named "MJL Korea,.Ltd". Our Web site address is http://www.mjl.co.kr We have made multimedia messaging system that supports VPIM version 3. We tiltled it "Lark Series 10". This system is world first DCOM (Distributed Component Object Model) based multimedia messaging system with high performance,capacity,fault tolerant . So. we ask you give me the way us to undergo a conformance test by EMA. How can we contact EMA about conformance testing about VPIM version 3 ? There is no writings on EMA's Home page about version 3 conformance test. Because we are to undergo a conformance test as soon as possible for our important business, we ask you how to. We are in needs of your help about it. Please Give us Reply . We will appreciate it. yangwj@mjl.co.kr Warm Regards. Bye. <> < Lark Series 10> ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Friday, March 12, 1999 6:50 pm To: 'ietf-imap-voice@imc.org' Cc: 'vpim-l@ema.org' Subject: RE: draft-ema-vpim-imap-00.txt Folks, Ooops. It seems that you may not have been able to read the I-D I sent out with Mac EOLs. Please review the version from the IETF archives: ftp://www.ietf.org/internet-drafts/draft-ema-vpim-imap-00.txt Thanks, Glenn. > ---------- > From: Parsons, Glenn [NORSE:6L45-I:EXCH] > Sent: Friday, February 26, 1999 8:45 PM > To: ietf-imap-voice@imc.org > Cc: 'vpim-l@ema.org' > Subject: draft-ema-vpim-imap-00.txt > > Folks, > > I was meaning to send the minutes from the December BOF to this list, but > as I finally got around to putting them together (since I never really > took many notes -- nor did anyone else I think) it made more sense to just > summarize the issues and the current suggestions and post them as a draft. > So that's what I did. > > I posted the draft today (and attached it here) that covers the topics > mentioned by Jutta in the intro message last month. All of the > suggestions for each of the IMAP voice extension topics were discussed in > December. > > Please review and comment. > > Do folks think that we need another informal BOF or should we work the > details out on the list? > > Cheers, > Glenn. > > <> > > -------------------------------------------------------- > Glenn Parsons Internet Messaging Standards > Nortel Networks > Phone: +1-613-763-7582 Ottawa, Ontario, CANADA > G3fax: +1-613-763-2697 > Email: Glenn.Parsons@NortelNetworks.com > > > ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Friday, March 12, 1999 6:50 pm To: 'ietf-imap-voice@imc.org' Cc: 'vpim-l@ema.org' Subject: RE: draft-ema-vpim-imap-00.txt Folks, Ooops. It seems that you may not have been able to read the I-D I sent out with Mac EOLs. Please review the version from the IETF archives: ftp://www.ietf.org/internet-drafts/draft-ema-vpim-imap-00.txt Thanks, Glenn. > ---------- > From: Parsons, Glenn [NORSE:6L45-I:EXCH] > Sent: Friday, February 26, 1999 8:45 PM > To: ietf-imap-voice@imc.org > Cc: 'vpim-l@ema.org' > Subject: draft-ema-vpim-imap-00.txt > > Folks, > > I was meaning to send the minutes from the December BOF to this list, but > as I finally got around to putting them together (since I never really > took many notes -- nor did anyone else I think) it made more sense to just > summarize the issues and the current suggestions and post them as a draft. > So that's what I did. > > I posted the draft today (and attached it here) that covers the topics > mentioned by Jutta in the intro message last month. All of the > suggestions for each of the IMAP voice extension topics were discussed in > December. > > Please review and comment. > > Do folks think that we need another informal BOF or should we work the > details out on the list? > > Cheers, > Glenn. > > <> > > -------------------------------------------------------- > Glenn Parsons Internet Messaging Standards > Nortel Networks > Phone: +1-613-763-7582 Ottawa, Ontario, CANADA > G3fax: +1-613-763-2697 > Email: Glenn.Parsons@NortelNetworks.com > > > ---------- From: Calum Loudon Sent: Friday, March 5, 1999 1:12 pm To: 'VPIM-L@EMA.org' Cc: Comverse - Orly Rappaport Subject: RE: VPIM Directory - X.500/LDAP >When considering directory server requirements, it's important to distinguish >between functions and protocols. > >If you want to connect multiple directory servers together to provide a >single seamless service for clients, you need two distinct functions: >- protocols which let individual directory servers talk to each other, either >by > - chaining, which allows a server to pass a client request to another >server, or > - replication, which allows the servers to synchronise data between them >- some way of identifying where a particular directory entry can be located >('knowledge' in X.500 terms). > >X.500 has specific server protocols for both chaining and replication. LDAP >servers can use the client access protocol (i.e. LDAP itself - technically >speaking, it's just a single client access protocol rather than a suite of >server standards) for chaining, and various replication protocols have been >suggested for LDAP v3 but are still being argued over. > >X.500 tells servers how to find particular entries via 'knowledge' references >- essentially, each server either knows where the data is itself or knows how >to get to a server which does. While this is great for finding data, it means >that you have to take a careful 'top-down' approach to building a directory >system - you can't just throw isolated X.500 systems together, as they may >have overlapping data. > >LDAP has no concept of knowledge - it really just is a client access protocol >rather than a description of how a server should work. While this means you >don't have to worry about overlapping data, it means you have a serious >problem when connecting multiple LDAP servers together. If you're just >connecting two LDAP servers then fine, simple chaining will do: 'if I haven't >got the data, chain the request to the other server'. But what if you're >connecting fifty or a hundred or a thousand? If you chain on to all of those >you have a scalability nightmare. > >You could use referrals, which is the closest LDAP comes to knowledge. In >these, if the server does not have the data itself it may return a list of >other servers for the client to query - but that means the clients have to do >all the work and chaining becomes pointless. Also, LDAP does not address how >the servers build up and maintain referral information. There is work being >done on this but it's still at a very early stage. > >What you really need is for an LDAP server which can perform intelligent >chaining e.g. following up the referrals itself, trying to predict the >likeliest server based on past requests, allowing you to configure rules >which suggest which servers to try first etc - essentially providing the >X.500 knowledge service but letting you build from the bottom-up rather than >the top-down. > >So, what does this mean in practice for building integrated VPIM directories? >- Obviously, the directory servers have to support LDAP for client access. >Most directory servers that support X.500 client access will also support >LDAP client access. >- If you want to connect a few of them together, you need a chaining or >replication protocol. Directory servers that support X.500 have these today. >Some directory servers that support LDAP can do chaining, and LDAP v3 will >probably introduce some form of replication. Most directory servers that >support X.500 will also support the LDAP server-to-server protocols, but >relatively few directory servers that support the LDAP server-to-server >protocols will also support the X.500 ones. >- If you want to connect a lot of them together, you must have some sort of >knowledge as well. Directory servers that support X.500 have this but the >protocol requires you to build top-down. Directory servers that just support >LDAP do not have this at all, and the only sensible way of doing this via >LDAP is having intelligent directory servers that can create knowledge from >the bottom-up. > >Calum Loudon >Messaging and Directory Group >Data Connection Ltd >Tel: +44 (0) 131 662 1212 Fax: +44 (0) 131 662 1345 >Email: cl@datcon.co.uk Web: http://www.datcon.co.uk > > > >---------- >From: Bernard Elliot[SMTP:BELLIOT@compuserve.com] >Sent: 25 February 1999 15:57 >To: EMA,VPIM-L >Subject: re: VPIM Directory - X.500/LDAP > >Orly, >Current planning for the VPIM trials is based on LDAP v2. The inclusion of >LDAP v3 will be considered when it is mature and participating companies >feel that it should be supported. Unifi is planning to post an example >directory for the trials shortly. > >So LDAP is sufficient. > >Useful directory background and references are on the ema web site at >www.ema.org/vpimdir/directory. > >An example schema developed by Anne Brown is at >ftp://ftp.isi.edu/internet-drafts/draft-ema-vpimdir-schema-00.txt. > >Bern Elliot >elliot@acm.org >---------- Forwarded Message ---------- > >From: "Rappaport, Orly", INTERNET:Orly_Rappaport@icomverse.com >TO: EMA, V Profile Inet Mail, INTERNET:vpim-l@ema.org >DATE: 2/25/99 7:21 AM > >RE: VPIM Directory - X.500/LDAP > > >I would appreciate your response to the following: >To be a VPIM directory server which: >1. Provides LDAP access to VPIM compliant systems AND >2. Can integrate with other VPIM directories >Is X.500 required or can LDAP server be sufficient? >Thanks >Orly Rapaport >Comverse Network Systems >Tel: +972-3-645.2658 (Fax: 2678) >E-mail: orly_rapaport@comverse.com > > > > > > > > > ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Monday, March 1, 1999 11:46 pm To: 'vpim-l@ema.org' Subject: FW: 44th IETF-MINNEAPOLIS, MN: VPIM BOF Folks, We have a VPIM BOF scheduled at the IETF meeting in Minneapolis on March 16th at 10:15am. I asked for 2 hours but time was tight so we only got 1 hour. The agenda I submitted for one hour was: Agenda: 00 - Agenda bashing 05 - Brief history of VPIM 10 - VPIM v2 (RFC 2421) interop testing for progression to Draft Standard 20 - VPIM v3 Goals 25 - VPIM v3 Unified Messaging (Primary content concept) 30 - VPIM v2 - v3 Interworking 35 - VPIM Addressing 40 - VPIM v3 Specification 50 - Wrap up and next steps 60 - Close The meeting is auditorium style and I did not ask to be broadcast (a la MBONE). We will not have a bridge as the meeting style does not suit that kind of interaction very well. What do you think of the agenda order? Will we be able to cover all the topics? Should we just ask the audience for comments? I think the structured tutorial approach (as in the agenda) is better as I am sure many attendees will be unfamiliar with what we have done and what we are now doing. As well, we want to try and cover as much as we can (and grab their interest) while we have an audience. Hopefully, the meeting will generate many new list members and increase participation. FYI, the description I cobbled together for the BOF follows (I presume this is what they will post on the IETF web site): Name: Voice Profile for Internet Mail (VPIM) BOF Description: The Voice Profile for Internet Mail (VPIM) is currently a Proposed Standard (RFC 2421). It is a profile of Internet Mail originally intended for sending voice messages between voice messaging systems. As such, VPIM imposes several restrictions on the message and transport to support the characteristics of voice messaging. Many voice mail vendors have implemented systems according to RFC 2421 and are in the process of deploying these systems around the world. Most vendors have completed (or are currently involved in) interoperability testing of VPIM products and have posted their results on the web. Though VPIM uses Internet Mail, because of its restrictions it is still somewhat awkward to send and receive messages from traditional desktop email clients. As a result, there is interest in loosening the restrictions of VPIM in a new version and make it more of a unified messaging protocol. This would make it easier for desktop clients to send and receive voice messages while maintaining support for the characteristics of a voice message. VPIM v3 is currently documented in several internet drafts (see draft-ema-vpimv3-*): VPIM v3 Goals, VPIM v3 Unified Messaging (Primary Content), VPIM Addressing, VPIM v2 - v3 Interworking and VPIM v3 Specification . The voice mail vendors and several email vendors have been meeting in the VPIM work group at the Electronic Messaging Association (EMA) for several years. This team produced VPIM v1 (RFC 1911) and VPIM v2 ( RFC 2421). This IETF meeting is intended to increase exposure to VPIM in the wider community, especially as we move to define VPIM v3. The current plan is to propose VPIM v2 for Draft Standard and VPIM v3 for Proposed Standard by summer 1999. For more information, see the VPIM web page: http://www.ema.org/vpim Mailing list: vpim-l@ema.org To subscribe: send a message to listserv@ema.org with 'subscribe VPIM-L' as the subject. Cheers, Glenn. > ---------- > From: Marcia Beaulieu > Sent: Monday, March 1, 1999 6:23 PM > To: Parsons, Glenn [NORSE:6L45-I:EXCH] > Cc: 'gregv@lucent.com'; 'moore@cs.utk.edu'; 'paf@swip.net' > Subject: 44th IETF-MINNEAPOLIS, MN: VPIM BOF > > This is to confirm one session for VPIM as follows: > > Tuesday, March 16 at 1015-1115 > other groups scheduled at that time: frnetmib, rps, xmldsig, ngtrans, > megaco, > malloc, mobileip > > > ********************************************************************** > Marcia Beaulieu > Meeting Coordinator > Voice: 703-620-8990 ext. 210 > Fax: 703-620-9071 > ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Monday, March 1, 1999 11:46 pm To: 'vpim-l@ema.org' Subject: FW: 44th IETF-MINNEAPOLIS, MN: VPIM BOF Folks, We have a VPIM BOF scheduled at the IETF meeting in Minneapolis on March 16th at 10:15am. I asked for 2 hours but time was tight so we only got 1 hour. The agenda I submitted for one hour was: Agenda: 00 - Agenda bashing 05 - Brief history of VPIM 10 - VPIM v2 (RFC 2421) interop testing for progression to Draft Standard 20 - VPIM v3 Goals 25 - VPIM v3 Unified Messaging (Primary content concept) 30 - VPIM v2 - v3 Interworking 35 - VPIM Addressing 40 - VPIM v3 Specification 50 - Wrap up and next steps 60 - Close The meeting is auditorium style and I did not ask to be broadcast (a la MBONE). We will not have a bridge as the meeting style does not suit that kind of interaction very well. What do you think of the agenda order? Will we be able to cover all the topics? Should we just ask the audience for comments? I think the structured tutorial approach (as in the agenda) is better as I am sure many attendees will be unfamiliar with what we have done and what we are now doing. As well, we want to try and cover as much as we can (and grab their interest) while we have an audience. Hopefully, the meeting will generate many new list members and increase participation. FYI, the description I cobbled together for the BOF follows (I presume this is what they will post on the IETF web site): Name: Voice Profile for Internet Mail (VPIM) BOF Description: The Voice Profile for Internet Mail (VPIM) is currently a Proposed Standard (RFC 2421). It is a profile of Internet Mail originally intended for sending voice messages between voice messaging systems. As such, VPIM imposes several restrictions on the message and transport to support the characteristics of voice messaging. Many voice mail vendors have implemented systems according to RFC 2421 and are in the process of deploying these systems around the world. Most vendors have completed (or are currently involved in) interoperability testing of VPIM products and have posted their results on the web. Though VPIM uses Internet Mail, because of its restrictions it is still somewhat awkward to send and receive messages from traditional desktop email clients. As a result, there is interest in loosening the restrictions of VPIM in a new version and make it more of a unified messaging protocol. This would make it easier for desktop clients to send and receive voice messages while maintaining support for the characteristics of a voice message. VPIM v3 is currently documented in several internet drafts (see draft-ema-vpimv3-*): VPIM v3 Goals, VPIM v3 Unified Messaging (Primary Content), VPIM Addressing, VPIM v2 - v3 Interworking and VPIM v3 Specification . The voice mail vendors and several email vendors have been meeting in the VPIM work group at the Electronic Messaging Association (EMA) for several years. This team produced VPIM v1 (RFC 1911) and VPIM v2 ( RFC 2421). This IETF meeting is intended to increase exposure to VPIM in the wider community, especially as we move to define VPIM v3. The current plan is to propose VPIM v2 for Draft Standard and VPIM v3 for Proposed Standard by summer 1999. For more information, see the VPIM web page: http://www.ema.org/vpim Mailing list: vpim-l@ema.org To subscribe: send a message to listserv@ema.org with 'subscribe VPIM-L' as the subject. Cheers, Glenn. ---------- From: Marcia Beaulieu Sent: Monday, March 1, 1999 6:23 PM To: Parsons, Glenn [NORSE:6L45-I:EXCH] Cc: 'gregv@lucent.com'; 'moore@cs.utk.edu'; 'paf@swip.net' Subject: 44th IETF-MINNEAPOLIS, MN: VPIM BOF This is to confirm one session for VPIM as follows: Tuesday, March 16 at 1015-1115 other groups scheduled at that time: frnetmib, rps, xmldsig, ngtrans, megaco, malloc, mobileip ********************************************************************** Marcia Beaulieu Meeting Coordinator Voice: 703-620-8990 ext. 210 Fax: 703-620-9071 ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Friday, February 26, 1999 4:45 pm To: ietf-imap-voice@imc.org Cc: 'vpim-l@ema.org' Subject: draft-ema-vpim-imap-00.txt <> Folks, I was meaning to send the minutes from the December BOF to this list, but as I finally got around to putting them together (since I never really took many notes -- nor did anyone else I think) it made more sense to just summarize the issues and the current suggestions and post them as a draft. So that's what I did. I posted the draft today (and attached it here) that covers the topics mentioned by Jutta in the intro message last month. All of the suggestions for each of the IMAP voice extension topics were discussed in December. Please review and comment. Do folks think that we need another informal BOF or should we work the details out on the list? Cheers, Glenn. <> -------------------------------------------------------- Glenn Parsons Internet Messaging Standards Nortel Networks Phone: +1-613-763-7582 Ottawa, Ontario, CANADA G3fax: +1-613-763-2697 Email: Glenn.Parsons@NortelNetworks.com ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Friday, February 26, 1999 3:34 pm To: ietf-fax@imc.org; 'vpim-l@ema.org' Subject: draft-ema-vpim-address-00.txt <> Folks, As promised, I have submitted (and attached) a document on VPIM addressing. It documents the addressing typical in existing VPIM v2 implementations and also defines the stricter LHS addressing proposed a year ago for inclusion in RFC2303/4. This document does not (yet) contain any IANA registrations that will be required based on Claudio's new version. Comments are welcome. Cheers, Glenn. <> -------------------------------------------------------- Glenn Parsons Internet Messaging Standards Nortel Networks Phone: +1-613-763-7582 Ottawa, Ontario, CANADA G3fax: +1-613-763-2697 Email: Glenn.Parsons@NortelNetworks.com ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Friday, February 26, 1999 3:34 pm To: ietf-fax@imc.org; 'vpim-l@ema.org' Subject: draft-ema-vpim-address-00.txt Folks, As promised, I have submitted (and attached) a document on VPIM addressing. It documents the addressing typical in existing VPIM v2 implementations and also defines the stricter LHS addressing proposed a year ago for inclusion in RFC2303/4. This document does not (yet) contain any IANA registrations that will be required based on Claudio's new version. Comments are welcome. Cheers, Glenn. <> -------------------------------------------------------- Glenn Parsons Internet Messaging Standards Nortel Networks Phone: +1-613-763-7582 Ottawa, Ontario, CANADA G3fax: +1-613-763-2697 Email: Glenn.Parsons@NortelNetworks.com ---------- From: Jutta Degener Sent: Thursday, February 25, 1999 7:39 pm To: vpim-l@ema.org Subject: Re: GSM codec & Ema minutes Glenn Parsons wrote: > My take is that GSM was favoured until we found out during the meeting that: > a) MS-GSM & GSM 6.10 codecs are quite different. It appears that the > framing, bit order and optimization are different. > b) Microsoft has IPR on MS-GSM I hope they rescind that claim; there's really not that much intellectual effort in packing GSM 06.10 frames behind a WAV header, which is all that's particular to MS's treatment of this ETSI-defined format. The differences between MS and Berlin GSM 06.10 are as follows: - MS GSM has a WAV envelope, - Berlin GSM has a four-bit leading "magic number" that brings the frame size to an integer multiple of bytes. - MS GSM frame bytes are packed in the opposite order from Berlin GSM frame bytes. The numbers transmitted are exactly the same. I expect the "optimization" Glenn mentions above is the half byte per frame less? I know all this because the Berlin GSM 06.10 library has supported MS-style framing (but not the WAV header) since early 1996, and so have many of its applications. The Berlin GSM 06.10 webpage, http://www.cs.tu-berlin.de/~jutta/toast.html talks about that a bit and links to sample source by Jeff Chilton that uses the library to produce a WAV files. The source is at http://www.cs.tu-berlin.de/~jutta/gsm/makewave.c To output binary data compatible with WAV format #49 (MS-GSM), a programmer has to - write the right WAV header (Jeff's sample code shows how) - turn on an option in the Berlin GSM encoder - encode the frames using the Berlin GSM encoder and know how many bytes to write on output (alternatingly 32 and 33). If you know how to write a WAV header, the rest are three gsm library calls. There is no penalty in quality or efficiency for using the MS format, and the library offers means to transcode from MS to Berlin format quickly without loss of quality. Jutta Degener ---------- From: Jonathan Taylor Sent: Thursday, February 25, 1999 4:11 pm To: VPIM-L@ema.org Subject: Re: Fwd: RE: GSM codec & Ema minutes Glenn: MS-GSM and GSM 6.10 are *not* quite different. In fact, the free source implementation supports both seamlessly. You can convert from one format to the other by just shifting bits around, and the source to the MS-GSM ACM codec implementation is (or at least was) included with the Microsoft driver SDK. I've looked at the Microsoft GSM source, and it was obviously built from the same ETSI psuedo code as the free source implementation. Perhaps the fellow from Microsoft just isn't familiar with the free source implementation. Any claim that we need to wait for info or IPR release from Microsoft in order to use either variety of GSM is FUD. -Jonathan Taylor -Chief Technology Officer -MediaGate, Inc. VPIM-L@listmail.ema.org wrote: > > Jonathan, > > > Could you summarize the codec discussion from EMA? > > > > In any case, it seems obvious that GSM is a defacto requirement for > > VPIM-3. More and more companies are using GSM in their "proprietary" > > solutions. The next step is to settle on Jutta framing vs. MS framing, > > if their is in fact a vs. > > > > > My take is that GSM was favoured until we found out during the meeting that: > a) MS-GSM & GSM 6.10 codecs are quite different. It appears that the > framing, bit order and optimization are different. > b) Microsoft has IPR on MS-GSM > > Microsoft will get back to us on the specific details of a) and what its > position on b) is. > > In the people present, I saw a shift of favour away from the GSM flavours > towards G.711 mu-law as the second codec (The WAV header was assumed as > optional in either case, I think). Remember we are talking about mandatory > for send & receive -- you can optionally use whatever codec you like as long > as you are confident that the recipient supports it. > > Of course, I favour no new base codecs. Microsoft indicated that they were > investigating bundling the G.726 codec into the next Windows. My favourite > mechanism to pick another codec is a capabilities negotiation based on the > internet fax work. > > Another interesting point that came up is that transcoding is bad -- > especially if done between linear/log/sub-band/wavelet/etc. codecs. It was > noted that messages are often forwarded 8-9 times in sales organizations... > > BTW, you can find a clean version of the minutes on the web page: > http://www.ema.org/vpimdir/minutes.html > > Cheers, > Glenn. ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Thursday, February 25, 1999 3:44 pm To: vpim-l@ema.org Subject: RE: GSM codec & Ema minutes Jonathan, > Could you summarize the codec discussion from EMA? > > In any case, it seems obvious that GSM is a defacto requirement for > VPIM-3. More and more companies are using GSM in their "proprietary" > solutions. The next step is to settle on Jutta framing vs. MS framing, > if their is in fact a vs. > > My take is that GSM was favoured until we found out during the meeting that: a) MS-GSM & GSM 6.10 codecs are quite different. It appears that the framing, bit order and optimization are different. b) Microsoft has IPR on MS-GSM Microsoft will get back to us on the specific details of a) and what its position on b) is. In the people present, I saw a shift of favour away from the GSM flavours towards G.711 mu-law as the second codec (The WAV header was assumed as optional in either case, I think). Remember we are talking about mandatory for send & receive -- you can optionally use whatever codec you like as long as you are confident that the recipient supports it. Of course, I favour no new base codecs. Microsoft indicated that they were investigating bundling the G.726 codec into the next Windows. My favourite mechanism to pick another codec is a capabilities negotiation based on the internet fax work. Another interesting point that came up is that transcoding is bad -- especially if done between linear/log/sub-band/wavelet/etc. codecs. It was noted that messages are often forwarded 8-9 times in sales organizations... BTW, you can find a clean version of the minutes on the web page: http://www.ema.org/vpimdir/minutes.html Cheers, Glenn. ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Thursday, February 25, 1999 1:14 pm To: 'vpim-l@ema.org' Cc: 'lauren.haywood@ema.org' Subject: VPIM Meeting Minutes <> Folks, I had expected EMA to post these minutes some time ago...but I have not seen them yet. So in the mean time here it is (the attendees may not be accurate). Glenn. (PS, note the codec discussion) ------------- Electronic Messaging Association Committee ClusterVoice Messaging Committee MinutesFebruary 3-4, 1999McLean, VAVoice Messaging Committee Chair: Bern Elliot of Elliot CommunicationsVoice Messaging Vice-Chair: Glenn Parsons of Nortel NetworksAttendees: Lance Mansfield of Active Voice Corporation, Greg Vaudreuil of Lucent Technologies OMD, Chris Ziang of Siemens, Marty Cohen of Nortel Networks, Stuart McRae of Lotus, Brian White of Sprint, LeLand Kirchoff of PulsePoint, Eli Jacobi of Comverse Network Systems, Ann Wheeler of Comverse Network Systems, Eric Burger of Centigram, Laile Di Silvestro of Microsoft Corporation, John Musa of Bell Atlantic.Bridged Participants: Mike Wilson of Lucent Technologies OMD, Mike Stonecipher of Sprint PCS, Bruce Armstrong of Novell, Cheryl Kinden of Nortel Networks.Meeting Agenda1. VPIM v3/Desktop - February 3, 8:30 am - 12:30 pm2. Inter-Company Voice Messaging User Agreements - February 3, 1:30 pm - 5:30 pm3. VPIM Bootcamp - February 4, 9:00 am - 12:30 pmVPIM v3/Desktop===============1) Lalie Di Silvestro -- VPIM's Goal Document Overview2) Greg Vaudreuil -- VPIM V3 Overview3) Glenn Parsons -- Multipart proposal4) VPIM V3 send/receive requirementsLalie Di Silvestro -- VPIM's Goal Document Overview (see slides)Primary goal is Interoperability. Specifically, interoperability with desktop email applications, VM and UM. There must be support for different capabilities and multiple codecs. Some specific interoperability goals are, little complexity to decode/encode, support Voice over IP, audio running from desktop, support devices with little memory/space such as the wireless desktop, support audio incapable clients, and support text incapable clients. To have interoperability with traditional email servers, VPIM must support all existing headers. (e.g. REPLY TO:)Comments:1) Orlando IETF VPIM BOF discussion validated need to include desktop VPIM awareness (recorder, helper app, full functionality)2) Understand the difference between email servers and UM systems3) Focus on not restricting the message header requirements across messaging system types4) Version 2 revision: Will clarify media reception sections as part of elevating VPIMv2 maturity from Proposed Standard to Draft Standard. No plans to change any v2 protocol.Move descriptive text from v3 spec into goals document.Formal IETF Working GroupIt may be necessary to split the work: - Technical Document (Specification) - IETF- Goals and Conformance - EMAIt may also be possible to finish the work in the IETF with only BOF status (finish in 2 meetings)Greg Vaudreuil -- VPIM Version 3Comment: What reviews have taken place?1) IETF IMAP BOF: binaries, streaming, client server requests2) IETF VPIM V3 BOF: Presented information from last VPIM work group meeting including an outline of messaging model; Attendees included: IRdg; bonsai; voceltec, MediaGate, Nortel, Qualcomm, Nokia, Motorola, CiscoComment: What did "fax message" mean in this discussion?1) VPIM V2 does address fax message within a voice message content type2) Content types and primary parts definitions will guide discard rules and presentationIssue review:1) CODECa) G.711 Mu-Law (agreed on as a requirement); A-Law is not a requirement - Only G.711 is guaranteed on as "may"; ii) IETF Fax: capabilities negotiation used between client systems (UAs); last call with the IESG iii) IETF MailCAP work: MTA, server based, but further out2) VCARDa) In order to be compatible with desktop viewers (i.e. VPIM helper apps that can not see the RFC822 headers), there is a MUST requirement for the VCARD content type to carry the originators address. Specifics regarding the VCARD email attribute needs to be worked out regarding the originators "VPIM address" with appropriate parameters, type = VPIM, Internet, fax. This requirement presumes that the desktop dispatches multi-part content to the same helper app vs separate helper apps. There was a comment that this requirement stems from the ability to reply to a voice (VPIM) message.b) Audio spoken name inside and outside the VCARD? Outside advantage retains the ability to transport the originator's spoken name as a content type (VPIM V2); Inside allows desktop helper apps to access this audio information; Backward compatibility to VPIM V2 is necessary as well. This would help existing VCARD helper apps because they cannot control what the email vendors hand them 3) Message Header Requirementsa) Need to reconcile VPIM V2 restrictions on the sender because there's more (and different) capabilities in an UM environment; At a high level, the VPIM V3 sender requirements would remove "must nots" and the receiver behavior with regard to these would be specifiedi) DRUMS work as guideline for sending features with implementation guidelines for reception; DRUMS is in IETF last call ii) Header "walk through" (1) "To" and "from" field should include implementation guidelines on a numeric LHS; Need additional detail on the AMIS-A and gateways; May have to have a separate document which contains guidelines (vs requirements); Glenn Parsons to author (2) If a receiving systems does not recognize the from field, it should not offer the reply capability(3) "Do not forward" requirement; Issue with backward compatibility with V2 (i.e. what happens when a VPIM V2 system sends a message marked sensitive to a VPIM V3 system); This remains an open issue. Also, service provider capabilities negotiation could support determining the destination domain in order to reject message transfer, and allow subsequent resubmission (e.g. without sensitivity)(4) "promotion": single part content is promoted to a message content type by some email clients and email server vendors; Semantics will be lost in a multipart/voice-message. Solve with must include vCard.(5) Content type should identify appropriate codec as a parameter of audio/wav (so that you do not have to open the audio to determine it is not supported)(6) Discard rule discussion; TBD(7) V3 ->V2 ; assumptions and details TBDVPIM V3 Milestones* VPIM V3 submitted as proposed standard on the following schedule:* Documents: Goals (2 weeks for review) VPIM V3 (2 weeks for review) Addressing (create) MIME registration (2 weeks for review) V3 -> V3 backdown issue (create)* February meeting update by end of February* IETF (Minneapolis) mid-March; presentation at BOF * EMA (Texas), end of March; review BOF comments for July IETF* Incorporate comments from March review* IETF proposed standard or BCP submissionInter-Company Voice Messaging User Agreements=============================================Leader: Bern Elliot, ECSee Document posted to VPIM-L Mailing List on Monday, Feb. 1st - Inter-Company Voice Messaging - Meeting NotesTopics for discussion:- Traffic volume and content agreement- Framework for addressing costs, settlements, bilateral agreements and grievances- VPIM (and other) standards conformance agreement- Service quality, levels and ethics (policy) agreement- Relationship to other messaging media- Enterprise administrator guidelines, recommendation and checklist- Directory and addressing- Governance1. High-level Design and agreement assumptionsTwo Objectives:- Lower barriers for Enterprise Administrators and Service Providers- Direction for agreements so different networks will have similar assumptions when they are interconnected.Three Documents:- Generic Agreement (Enterprise - Enterprise, Enterprise - Service Provider, Service Provider - Service Provider)- Enterprise and Service Provider System Administrator Guide/Guidelines- Plan for how agreement evaluation will proceed (Period of time)2. Directory and AddressingTwo LevelsAll information is not stored at the top, but in two levels. The first query will go to the top-level directory and the top level directs it to the appropriate second level directory.For example:Query: I have this phone number. Is there a directory where I can get more information on this number?Top Level: Oh, this number belongs to company xyz. You can get information at xyz company directory (where xyz company directory would be the second level)The two level approach is important because companies are likely to be concerned about giving out directory information to anyone. There were several suggestions:- The response could be something like "I know this person and I can deliver the message for you. Send it to ..."- The response could be "If you are sending a message to an employee at company xyz, send it to 1+area code+number@xyz.com. If it turns out that the employee doesn't exist you will get an NDN." With this type of response at the top level you wouldn't need a second level directory.- The response could also give a range of telephone numbers and give a response like "If you want to send a message to anyone in this number range, address it to number@xyz.com"No decisions made at this point.3. VPIM (and other) Standards Conformance Agreement Classes of agreement for the trials:Top Level - Support NDN and DN . .Bottom Level - No DN. Try to give NDN using SMTP Gateway.4. Governance and Grievance PolicyNeed a clear definition of legal responsibility.The drafts should be prepared as the trials are done and document templates should be produced as a result of the trials.There will be an EMA Web Site where companies will post their VPIM implementations. In this way any problems will be known to others. This can act as a governance/grievance in the way that if a company wants an agreement with you, you can scan the list for problems. Then if you find considerable problems or repeats you can put a separate clause in your agreement addressing this concern.5. Costs and SettlementsEnterprises are unlikely to want to charge for voice messaging whereas charging is very important to service providers.Billing was discussed. No solutions yet.- One method is to use SMTP AUTH command and give each message a billing reference- VMA suggests using the GSM Settlement MoU (ETSI TAGID) as a guide7. Relationship to other messaging mediaEmail messages would have to be limited in size to something reasonable.The initial trial would likely only involve VPIMv2 systems, as VPIMv3 is in initial stages at the present time. Additional capabilities may be added later, as vendors begin support for VPIMv3 in products.8. Enterprise Administrator Guidelines, Recommendation and ChecklistHewlett Packard has documents already in place for the AMIS network, on addressing for user and administrator. They would be willing to provide input to be used as a base for the guidelines.9. Traffic Volume and Content AgreementDelivery Time - There are two possible suggestions on how to set a target delivery time:- Use market studies to find out how fast customers want. (Bell Atlantic has a result from a Bellcore study on this.- Use trial times to see how fast messages are being delivered.Data Message Format- Billing Information- Traffic InformationIdeas are welcome on how to collect the Network measurement data (See Table A)10. Other Services and FeaturesExamples: Anti-Spam, Caller-ID BlockComments:- General consensus was that this work item should indeed be continued. (Straw Poll - majority support)- Companies would like to see trial activity starting in the July/August time frame- There is a document on the web showing vendors that support VPIM- In Europe there have been vendor - service provider teams set up for trials- Time Frame Goal is to try and get drafts together by March, to coincide with the VPIMv3 spec time-frame goals.- HP will provide input on administrator guidelines- Control Data, UNIFI will lead Directory work- Comverse will lead other services (Anti-Spam, etc.)- Glenn Parsons will provide support in directory addressing- Bern Elliot will provide follow-upVPIM Bootcamp=============* Review of Testing Goals and VPIMv2 Features* Description of Testing Process - Test by Test* What you need to do before you start testing * Posting Positive results on Web * Marketing Requirements for participationComments:- Test 7 (Section 3.3.3, VOICE MESSAGING INTEROPERABILITY:Testing Guidelines for VPIMv2 Products)Include Recommendation: Should test multiple vendor hops - At least 2 hops ?- Clarification - Compatibility vs InteroperabilityCompatibility Statement/Declaration requires no testing. This is just the vendor's statement of compliance. Interoperability declaration requires at least three tests - with yourself, and with at least 2 other products.- How to fill out the compatibility documentClarify the feature supportIf you check a MUST NOT, it means that you don't do that featureSHOULD NOT - a check means that you support - you don't do that featureEssentially "Ticks are Good" so the more the better For compliance, minimum checks are the MUSTs and the MUST NOTs- How long will the testing process take?If you do casual testing (i.e. send and receive a few messages per day plus examining messages while doing other things), it should take about 2-3 weeks to complete testing.If your testers are dedicated to non-stop testing with no time zone issues, it should only take about 2-3 days to complete.Testing Readiness for VPIMv2Lucent (IMA-ML 1.x) - Now, Lucent (IMA-ML 2.x, Intuitity IMA-ESP) - 2Q 99 Lucent (Unified Messenger) - ???Comverse (INF) - ? 99 Comverse (Access ANP) - 1Q 99 Active Voice (Unity) - ? 99Nortel (CallPilot, MMNG, NVM) - NowBrite - 2Q 99Technomen - ? 99DCL - ? 99Glenayre - ? 99Others ? > <> > ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Thursday, February 25, 1999 3:44 pm To: vpim-l@ema.org Subject: RE: GSM codec & Ema minutes Jonathan, Could you summarize the codec discussion from EMA? In any case, it seems obvious that GSM is a defacto requirement for VPIM-3. More and more companies are using GSM in their "proprietary" solutions. The next step is to settle on Jutta framing vs. MS framing, if their is in fact a vs. My take is that GSM was favoured until we found out during the meeting that: a) MS-GSM & GSM 6.10 codecs are quite different. It appears that the framing, bit order and optimization are different. b) Microsoft has IPR on MS-GSM Microsoft will get back to us on the specific details of a) and what its position on b) is. In the people present, I saw a shift of favour away from the GSM flavours towards G.711 mu-law as the second codec (The WAV header was assumed as optional in either case, I think). Remember we are talking about mandatory for send & receive -- you can optionally use whatever codec you like as long as you are confident that the recipient supports it. Of course, I favour no new base codecs. Microsoft indicated that they were investigating bundling the G.726 codec into the next Windows. My favourite mechanism to pick another codec is a capabilities negotiation based on the internet fax work. Another interesting point that came up is that transcoding is bad -- especially if done between linear/log/sub-band/wavelet/etc. codecs. It was noted that messages are often forwarded 8-9 times in sales organizations... BTW, you can find a clean version of the minutes on the web page: http://www.ema.org/vpimdir/minutes.html Cheers, Glenn. ---------- From: Jonathan Taylor Sent: Thursday, February 25, 1999 2:18 pm To: vpim-l@ema.org Subject: GSM codec & Ema minutes Glenn: Could you summarize the codec discussion from EMA? The only thing I could find in the text was a brief mention of G.711, and the DOC file came up unreadable on my copy of word. In any case, it seems obvious that GSM is a defacto requirement for VPIM-3. More and more companies are using GSM in their "proprietary" solutions. The next step is to settle on Jutta framing vs. MS framing, if their is in fact a vs. Thanks, -Jonathan Taylor -Chief Technology Officer -MediaGate ---------- From: Jonathan Taylor Sent: Thursday, February 25, 1999 2:14 pm To: VPIM-L@listmail.ema.org Subject: Re: Fwd: VPIM Meeting Minutes Glenn: Could you summarize the codec discussion? The text was very hard to read--I only saw a brief mention of G.711, and the doc file came up as gibberish in my copy of word. In any case, it seems obvious that some form of GSM is a defacto requirement for VPIM-3. Now we need to get the framing types right. Thanks. -Jonathan VPIM-L@listmail.ema.org wrote: > > Folks, > > I had expected EMA to post these minutes some time ago...but I have not seen > them yet. So in the mean time here it is (the attendees may not be > accurate). > > Glenn. > > (PS, note the codec discussion) > > ------------- > > Electronic Messaging Association Committee ClusterVoice Messaging Committee MinutesFebruary 3-4, 1999McLean, VAVoice Messaging Committee Chair: Bern Elliot of Elliot CommunicationsVoice Messaging Vice-Chair: Glenn Parsons of Nortel NetworksAttendees: Lance Mansfield of Active Voice Corporation, Greg Vaudreuil of Lucent Technologies OMD, Chris Ziang of Siemens, Marty Cohen of Nortel Networks, > Stuart McRae of Lotus, Brian White of Sprint, LeLand Kirchoff of PulsePoint, Eli > Jacobi of Comverse Network Systems, Ann Wheeler of Comverse Network Systems, Eric Burger of Centigram, Laile Di Silvestro of Microsoft Corporation, John Musa > of Bell Atlantic.Bridged Participants: Mike Wilson of Lucent Technologies OMD, Mike Stonecipher of Sprint PCS, Bruce > Armstrong of Novell, Cheryl Kinden of Nortel Networks.Meeting Agenda1. VPIM v3/Desktop - February 3, 8:30 am - 12:30 pm2. Inter-Company Voice Messaging User Agreements - February 3, 1:30 pm - 5:30 > pm3. VPIM Bootcamp - February 4, 9:00 am - 12:30 pmVPIM v3/Desktop===============1) Lalie Di Silvestro -- VPIM's Goal Document Overview2) Greg Vaudreuil -- VPIM V3 Overview3) Glenn Parsons -- Multipart proposal4) VPIM V3 send/receive requirementsLalie Di Silvestro -- VPIM's Goal Document Overview (see slides)Primary goal is Interoperability. Specifically, interoperability with > desktop email applications, VM and UM. There must be support for different > capabilities and multiple codecs. Some specific interoperability goals are, little > complexity to decode/encode, support Voice over IP, audio running from desktop, support devices with little memory/space such as the wireless desktop, support audio incapable clients, and support text incapable clients. To have interoperability with traditional email servers, VPIM must support > all existing headers. (e.g. REPLY TO:)Comments:1) Orlando IETF VPIM BOF discussion validated need to include desktop VPIM awareness (recorder, helper app, full functionality)2) Understand the difference between email servers and UM systems3) Focus on not restricting the message header requirements across messaging system types4) Version 2 revision: Will clarify media reception sections as part of elevating VPIMv2 maturity from Proposed Standard to Draft Standard. No plans > to change any v2 protocol.Move descriptive text from v3 spec into goals document.Formal IETF Working GroupIt may be necessary to split the work: - Technical Document (Specification) - IETF- Goals and Conformance - EMAIt may also be possible to finish the work in the IETF with only BOF status (finish in 2 meetings)Greg Vaudreuil -- VPIM Version 3Comment: What reviews have taken place?1) IETF IMAP BOF: binaries, streaming, client server requests2) IETF VPIM V3 BOF: Presented information from last VPIM work group meeting including an outline of messaging model; Attendees included: IRdg; bonsai; voceltec, MediaGate, Nortel, Qualcomm, Nokia, Motorola, CiscoComment: What did "fax message" mean in this discussion?1) VPIM V2 does address fax message within a voice message content type2) Content types and primary parts definitions will guide discard rules and presentationIssue review:1) CODECa) G.711 Mu-Law (agreed on as a requirement); A-Law is not a requirement - Only G.711 ! is > guaranteed > on > as "may"; ii) IETF Fax: capabilities negotiation used between client systems (UAs); > last call with the IESG iii) IETF MailCAP work: MTA, server based, but further out2) VCARDa) In order to be compatible with desktop viewers (i.e. VPIM helper apps > that can not see the RFC822 headers), there is a MUST requirement for the VCARD content type to carry the originators address. Specifics regarding the VCARD email attribute needs to be worked out regarding the originators "VPIM > address" with appropriate parameters, type = VPIM, Internet, fax. This requirement presumes that the desktop dispatches multi-part content to the same helper > app vs separate helper apps. There was a comment that this requirement stems > from the ability to reply to a voice (VPIM) message.b) Audio spoken name inside and outside the VCARD? Outside advantage retains > the ability to transport the originator's spoken name as a content type (VPIM > V2); Inside allows desktop helper apps to access this audio information; Backward compatibility to VPIM V2 is necessary as well. This would help existing VCARD helper apps because they cannot control what the email vendors > hand them 3) Message Header Requirementsa) Need to reconcile VPIM V2 restrictions on the sender because there's more > (and different) capabilities in an UM environment; At a high level, the VPIM > V3 sender requirements would remove "must nots" and the receiver behavior with regard to these would be specifiedi) DRUMS work as guideline for sending features with implementation > guidelines for reception; DRUMS is in IETF last call ii) Header "walk through" (1) "To" and "from" field should include implementation guidelines on a > numeric LHS; Need additional detail on the AMIS-A and gateways; May have to have a separate document which contains guidelines (vs requirements); Glenn Parsons > to author (2) If a receiving systems does not recognize the from field, it should not offer the reply capability(3) "Do not forward" requirement; Issue with backward compatibility with V2 (i.e. what happens when a VPIM V2 system sends a message marked sensitive to > a VPIM V3 system); This remains an open issue. Also, service provider capabilities negotiation could support determining the destination domain in order to reject message transfer, and allow subsequent resubmission (e.g. without sensitivity)(4) "promotion": single part content is promoted to a message content type by > some email clients and email server vendors; Semantics will be lost in a multipart/voice-message. Solve with must include vCard.(5) Content type should identify appropriate codec as a parameter of > audio/wav (so that you do not have to open the audio to determine it is not supported)(6) Discard rule discussion; TBD(7) V3 ->V2 ; assumptions and details TBDVPIM V3 Milestones* VPIM V3 submitted as proposed standard on the following schedule:* Documents: Goals (2 weeks for review) VPIM V3 (2 weeks for review) Addressing (create) MIME registration (2 weeks for review) V3 -> V3 backdown issue (create)* February meeting update by end of February* IETF (Minneapolis) mid-March; presentation at BOF * EMA (Texas), end of March; review BOF comments for July IETF* Incorporate comments from March review* IETF proposed standard or BCP submissionInter-Company Voice Messaging User Agreements=============================================Leader: Bern Elliot, ECSee Document posted to VPIM-L Mailing List on Monday, Feb. 1st - > Inter-Company Voice Messaging - Meeting NotesTopics for discussion:- Traffic volume and content agreement- Framework for addressing costs, settlements, bilateral agreements and grievances- VPIM (and other) standards conformance agreement- Service quality, levels and ethics (policy) agreement- Relationship to other messaging media- Enterprise administrator guidelines, recommendation and checklist- Directory and addressing- Governance1. High-level Design and agreement assumptionsTwo Objectives:- Lower barriers for Enterprise Administrators and Service Providers- Direction for agreements so different networks will have similar > assumptions when they are interconnected.Three Documents:- Generic Agreement (Enterprise - Enterprise, Enterprise - Service Provider, Service Provider - Service Provider)- Enterprise and Service Provider System Administrator Guide/Guidelines- Plan for how agreement evaluation will proceed (Period of time)2. Directory and AddressingTwo LevelsAll information is not stored at the top, but in two levels. The first query > will go to the top-level directory and the top level directs it to the appropriate second level directory.For example:Query: I have this phone number. Is there a directory where I can get more information on this number?Top Level: Oh, this number belongs to company xyz. You can get information > at xyz company directory (where xyz company directory would be the second level)The two level approach is important because companies are likely to be > concerned about giving out directory information to anyone. There were several suggestions:- The response could be something like "I know this person and I can deliver > the message for you. Send it to ..."- The response could be "If you are sending a message to an employee at > company xyz, send it to 1+area code+number@xyz.com. If it turns out that the > employee doesn't exist you will get an NDN." With this type of response at the top > level you wouldn't need a second level directory.- The response could also give a range of telephone numbers and give a > response like "If you want to send a message to anyone in this number range, address > it to number@xyz.com"No decisions made at this point.3. VPIM (and other) Standards Conformance Agreement Classes of agreement for the trials:Top Level - Support NDN and DN . .Bottom Level - No DN. Try to give NDN using SMTP Gateway.4. Governance and Grievance PolicyNeed a clear definition of legal responsibility.The drafts should be prepared as the trials are done and document templates should be produced as a result of the trials.There will be an EMA Web Site where companies will post their VPIM implementations. In this way any problems will be known to others. This can > act as a governance/grievance in the way that if a company wants an agreement > with you, you can scan the list for problems. Then if you find considerable problems or repeats you can put a separate clause in your agreement > addressing this concern.5. Costs and SettlementsEnterprises are unlikely to want to charge for voice messaging whereas > charging is very important to service providers.Billing was discussed. No solutions yet.- One method is to use SMTP AUTH command and give each message a billing reference- VMA suggests using the GSM Settlement MoU (ETSI TAGID) as a guide7. Relationship to other messaging mediaEmail messages would have to be limited in size to something reasonable.The initial trial would likely only involve VPIMv2 systems, as VPIMv3 is in initial stages at the present time. Additional capabilities may be added > later, as vendors begin support for VPIMv3 in products.8. Enterprise Administrator Guidelines, Recommendation and ChecklistHewlett Packard has documents already in place for the AMIS network, on addressing for user and administrator. They would be willing to provide > input to be used as a base for the guidelines.9. Traffic Volume and Content AgreementDelivery Time - There are two possible suggestions on how to set a target delivery time:- Use market studies to find out how fast customers want. (Bell Atlantic has > a result from a Bellcore study on this.- Use trial times to see how fast messages are being delivered.Data Message Format- Billing Information- Traffic InformationIdeas are welcome on how to collect the Network measurement data (See Table > A)10. Other Services and FeaturesExamples: Anti-Spam, Caller-ID BlockComments:- General consensus was that this work item should indeed be continued. > (Straw Poll - majority support)- Companies would like to see trial activity starting in the July/August time > frame- There is a document on the web showing vendors that support VPIM- In Europe there have been vendor - service provider teams set up for trials- Time Frame Goal is to try and get drafts together by March, to coincide > with the VPIMv3 spec time-frame goals.- HP will provide input on administrator guidelines- Control Data, UNIFI will lead Directory work- Comverse will lead other services (Anti-Spam, etc.)- Glenn Parsons will provide support in directory addressing- Bern Elliot will provide follow-upVPIM Bootcamp=============* Review of Testing Goals and VPIMv2 Features* Description of Testing Process - Test by Test* What you need to do before you start testing * Posting Positive results on Web * Marketing Requirements for participationComments:- Test 7 (Section 3.3.3, VOICE MESSAGING INTEROPERABILITY:Testing Guidelines > for VPIMv2 Products)Include Recommendation: Should test multiple vendor hops - At least 2 hops ?- Clarification - Compatibility vs InteroperabilityCompatibility Statement/Declaration requires no testing. This is just the vendor's statement of compliance. Interoperability declaration requires at least three tests - with yourself, > and with at least 2 other products.- How to fill out the compatibility documentClarify the feature supportIf you check a MUST NOT, it means that you don't do that featureSHOULD NOT - a check means that you support - you don't do that featureEssentially "Ticks are Good" so the more the better For compliance, minimum checks are the MUSTs and the MUST NOTs- How long will the testing process take?If you do casual testing (i.e. send and receive a few messages per day plus examining messages while doing other things), it should take about 2-3 weeks > to complete testing.If your testers are dedicated to non-stop testing with no time zone issues, > it should only take about 2-3 days to complete.Testing Readiness for VPIMv2Lucent (IMA-ML 1.x) - Now, Lucent (IMA-ML 2.x, Intuitity IMA-ESP) - 2Q 99 Lucent (Unified Messenger) - ???Comverse (INF) - ? 99 Comverse (Access ANP) - 1Q 99 Active Voice (Unity) - ? 99Nortel (CallPilot, MMNG, NVM) - NowBrite - 2Q 99Technomen - ? 99DCL - ? 99Glenayre - ? 99Others ? > > > <> > > > > ------------------------------------------------------------------------ > Name: ema990203.doc > ema990203.doc Type: Winword File (application/msword) > Encoding: Base64 ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Thursday, February 25, 1999 1:14 pm To: 'vpim-l@ema.org' Cc: 'lauren.haywood@ema.org' Subject: VPIM Meeting Minutes Folks, I had expected EMA to post these minutes some time ago...but I have not seen them yet. So in the mean time here it is (the attendees may not be accurate). Glenn. (PS, note the codec discussion) ------------- Electronic Messaging Association Committee Cluster Voice Messaging Committee Minutes February 3-4, 1999 McLean, VA Voice Messaging Committee Chair: Bern Elliot of Elliot Communications Voice Messaging Vice-Chair: Glenn Parsons of Nortel Networks Attendees: Lance Mansfield of Active Voice Corporation, Greg Vaudreuil of Lucent Technologies OMD, Chris Ziang of Siemens, Marty Cohen of Nortel Networks, Stuart McRae of Lotus, Brian White of Sprint, LeLand Kirchoff of PulsePoint, Eli Jacobi of Comverse Network Systems, Ann Wheeler of Comverse Network Systems, Eric Burger of Centigram, Laile Di Silvestro of Microsoft Corporation, John Musa of Bell Atlantic. Bridged Participants: Mike Wilson of Lucent Technologies OMD, Mike Stonecipher of Sprint PCS, Bruce Armstrong of Novell, Cheryl Kinden of Nortel Networks. Meeting Agenda 1. VPIM v3/Desktop - February 3, 8:30 am - 12:30 pm 2. Inter-Company Voice Messaging User Agreements - February 3, 1:30 pm - 5:30 pm 3. VPIM Bootcamp - February 4, 9:00 am - 12:30 pm VPIM v3/Desktop =============== 1) Lalie Di Silvestro -- VPIM's Goal Document Overview 2) Greg Vaudreuil -- VPIM V3 Overview 3) Glenn Parsons -- Multipart proposal 4) VPIM V3 send/receive requirements Lalie Di Silvestro -- VPIM's Goal Document Overview (see slides) Primary goal is Interoperability. Specifically, interoperability with desktop email applications, VM and UM. There must be support for different capabilities and multiple codecs. Some specific interoperability goals are, little complexity to decode/encode, support Voice over IP, audio running from desktop, support devices with little memory/space such as the wireless desktop, support audio incapable clients, and support text incapable clients. To have interoperability with traditional email servers, VPIM must support all existing headers. (e.g. REPLY TO:) Comments: 1) Orlando IETF VPIM BOF discussion validated need to include desktop VPIM awareness (recorder, helper app, full functionality) 2) Understand the difference between email servers and UM systems 3) Focus on not restricting the message header requirements across messaging system types 4) Version 2 revision: Will clarify media reception sections as part of elevating VPIMv2 maturity from Proposed Standard to Draft Standard. No plans to change any v2 protocol. Move descriptive text from v3 spec into goals document. Formal IETF Working Group It may be necessary to split the work: - Technical Document (Specification) - IETF - Goals and Conformance - EMA It may also be possible to finish the work in the IETF with only BOF status (finish in 2 meetings) Greg Vaudreuil -- VPIM Version 3 Comment: What reviews have taken place? 1) IETF IMAP BOF: binaries, streaming, client server requests 2) IETF VPIM V3 BOF: Presented information from last VPIM work group meeting including an outline of messaging model; Attendees included: IRdg; bonsai; voceltec, MediaGate, Nortel, Qualcomm, Nokia, Motorola, Cisco Comment: What did "fax message" mean in this discussion? 1) VPIM V2 does address fax message within a voice message content type 2) Content types and primary parts definitions will guide discard rules and presentation Issue review: 1) CODEC a) G.711 Mu-Law (agreed on as a requirement); A-Law is not a requirement - Only G.711 is guaranteed on desktops - Lose streaming capability (over dialup lines) - Perfectly viable option for LAN-based voicemail b) G.726 (agreed on as a requirement) - No IP - This is the codec used in VPIMv2 - Microsoft is looking into G.726 support c) GSM 6.10 (different from MS GSM) - GSM 6.10 won't guarantee desktop interoperability. Laile Di Silvestro indicated that MS-GSM (Deployed on Microsoft Desktops) is not necessarily compliant with GSM 6.10 deployed on other desktops (frames, bit order, optimization). This presents an IPR issue and it is not a viable codec unless - Microsoft will release IPR for this codec (hopefully free) - It is available on other platforms (Mac, UNIX) TBD. In light of new information presented, more facts are needed. Laile Di Silvestro to get more information on MS-GSM vs GSM 6.10. d) G 723.1: licensing issue; G.729, G.723.1, eliminated as an option i) Glenn proposes one manditory codec - G.726. MUST send/receive G.726 and receive WAV with GSM encoding; and use of capabilities negotiation designated as "may"; ii) IETF Fax: capabilities negotiation used between client systems (UAs); last call with the IESG iii) IETF MailCAP work: MTA, server based, but further out 2) VCARD a) In order to be compatible with desktop viewers (i.e. VPIM helper apps that can not see the RFC822 headers), there is a MUST requirement for the VCARD content type to carry the originators address. Specifics regarding the VCARD email attribute needs to be worked out regarding the originators "VPIM address" with appropriate parameters, type = VPIM, Internet, fax. This requirement presumes that the desktop dispatches multi-part content to the same helper app vs separate helper apps. There was a comment that this requirement stems from the ability to reply to a voice (VPIM) message. b) Audio spoken name inside and outside the VCARD? Outside advantage retains the ability to transport the originator's spoken name as a content type (VPIM V2); Inside allows desktop helper apps to access this audio information; Backward compatibility to VPIM V2 is necessary as well. This would help existing VCARD helper apps because they cannot control what the email vendors hand them 3) Message Header Requirements a) Need to reconcile VPIM V2 restrictions on the sender because there's more (and different) capabilities in an UM environment; At a high level, the VPIM V3 sender requirements would remove "must nots" and the receiver behavior with regard to these would be specified i) DRUMS work as guideline for sending features with implementation guidelines for reception; DRUMS is in IETF last call ii) Header "walk through" (1) "To" and "from" field should include implementation guidelines on a numeric LHS; Need additional detail on the AMIS-A and gateways; May have to have a separate document which contains guidelines (vs requirements); Glenn Parsons to author (2) If a receiving systems does not recognize the from field, it should not offer the reply capability (3) "Do not forward" requirement; Issue with backward compatibility with V2 (i.e. what happens when a VPIM V2 system sends a message marked sensitive to a VPIM V3 system); This remains an open issue. Also, service provider capabilities negotiation could support determining the destination domain in order to reject message transfer, and allow subsequent resubmission (e.g. without sensitivity) (4) "promotion": single part content is promoted to a message content type by some email clients and email server vendors; Semantics will be lost in a multipart/voice-message. Solve with must include vCard. (5) Content type should identify appropriate codec as a parameter of audio/wav (so that you do not have to open the audio to determine it is not supported) (6) Discard rule discussion; TBD (7) V3 ->V2 ; assumptions and details TBD VPIM V3 Milestones * VPIM V3 submitted as proposed standard on the following schedule: * Documents: Goals (2 weeks for review) VPIM V3 (2 weeks for review) Addressing (create) MIME registration (2 weeks for review) V3 -> V3 backdown issue (create) * February meeting update by end of February * IETF (Minneapolis) mid-March; presentation at BOF * EMA (Texas), end of March; review BOF comments for July IETF * Incorporate comments from March review * IETF proposed standard or BCP submission Inter-Company Voice Messaging User Agreements ============================================= Leader: Bern Elliot, EC See Document posted to VPIM-L Mailing List on Monday, Feb. 1st - Inter-Company Voice Messaging - Meeting Notes Topics for discussion: - Traffic volume and content agreement - Framework for addressing costs, settlements, bilateral agreements and grievances - VPIM (and other) standards conformance agreement - Service quality, levels and ethics (policy) agreement - Relationship to other messaging media - Enterprise administrator guidelines, recommendation and checklist - Directory and addressing - Governance 1. High-level Design and agreement assumptions Two Objectives: - Lower barriers for Enterprise Administrators and Service Providers - Direction for agreements so different networks will have similar assumptions when they are interconnected. Three Documents: - Generic Agreement (Enterprise - Enterprise, Enterprise - Service Provider, Service Provider - Service Provider) - Enterprise and Service Provider System Administrator Guide/Guidelines - Plan for how agreement evaluation will proceed (Period of time) 2. Directory and Addressing Two Levels All information is not stored at the top, but in two levels. The first query will go to the top-level directory and the top level directs it to the appropriate second level directory. For example: Query: I have this phone number. Is there a directory where I can get more information on this number? Top Level: Oh, this number belongs to company xyz. You can get information at xyz company directory (where xyz company directory would be the second level) The two level approach is important because companies are likely to be concerned about giving out directory information to anyone. There were several suggestions: - The response could be something like "I know this person and I can deliver the message for you. Send it to ..." - The response could be "If you are sending a message to an employee at company xyz, send it to 1+area code+number@xyz.com. If it turns out that the employee doesn't exist you will get an NDN." With this type of response at the top level you wouldn't need a second level directory. - The response could also give a range of telephone numbers and give a response like "If you want to send a message to anyone in this number range, address it to number@xyz.com" No decisions made at this point. 3. VPIM (and other) Standards Conformance Agreement Classes of agreement for the trials: Top Level - Support NDN and DN . . Bottom Level - No DN. Try to give NDN using SMTP Gateway. 4. Governance and Grievance Policy Need a clear definition of legal responsibility. The drafts should be prepared as the trials are done and document templates should be produced as a result of the trials. There will be an EMA Web Site where companies will post their VPIM implementations. In this way any problems will be known to others. This can act as a governance/grievance in the way that if a company wants an agreement with you, you can scan the list for problems. Then if you find considerable problems or repeats you can put a separate clause in your agreement addressing this concern. 5. Costs and Settlements Enterprises are unlikely to want to charge for voice messaging whereas charging is very important to service providers. Billing was discussed. No solutions yet. - One method is to use SMTP AUTH command and give each message a billing reference - VMA suggests using the GSM Settlement MoU (ETSI TAGID) as a guide 7. Relationship to other messaging media Email messages would have to be limited in size to something reasonable. The initial trial would likely only involve VPIMv2 systems, as VPIMv3 is in initial stages at the present time. Additional capabilities may be added later, as vendors begin support for VPIMv3 in products. 8. Enterprise Administrator Guidelines, Recommendation and Checklist Hewlett Packard has documents already in place for the AMIS network, on addressing for user and administrator. They would be willing to provide input to be used as a base for the guidelines. 9. Traffic Volume and Content Agreement Delivery Time - There are two possible suggestions on how to set a target delivery time: - Use market studies to find out how fast customers want. (Bell Atlantic has a result from a Bellcore study on this. - Use trial times to see how fast messages are being delivered. Data Message Format - Billing Information - Traffic Information Ideas are welcome on how to collect the Network measurement data (See Table A) 10. Other Services and Features Examples: Anti-Spam, Caller-ID Block Comments: - General consensus was that this work item should indeed be continued. (Straw Poll - majority support) - Companies would like to see trial activity starting in the July/August time frame - There is a document on the web showing vendors that support VPIM - In Europe there have been vendor - service provider teams set up for trials - Time Frame Goal is to try and get drafts together by March, to coincide with the VPIMv3 spec time-frame goals. - HP will provide input on administrator guidelines - Control Data, UNIFI will lead Directory work - Comverse will lead other services (Anti-Spam, etc.) - Glenn Parsons will provide support in directory addressing - Bern Elliot will provide follow-up VPIM Bootcamp ============= * Review of Testing Goals and VPIMv2 Features * Description of Testing Process - Test by Test * What you need to do before you start testing * Posting Positive results on Web * Marketing Requirements for participation Comments: - Test 7 (Section 3.3.3, VOICE MESSAGING INTEROPERABILITY:Testing Guidelines for VPIMv2 Products) Include Recommendation: Should test multiple vendor hops - At least 2 hops ? - Clarification - Compatibility vs Interoperability Compatibility Statement/Declaration requires no testing. This is just the vendor's statement of compliance. Interoperability declaration requires at least three tests - with yourself, and with at least 2 other products. - How to fill out the compatibility document Clarify the feature support If you check a MUST NOT, it means that you don't do that feature SHOULD NOT - a check means that you support - you don't do that feature Essentially "Ticks are Good" so the more the better For compliance, minimum checks are the MUSTs and the MUST NOTs - How long will the testing process take? If you do casual testing (i.e. send and receive a few messages per day plus examining messages while doing other things), it should take about 2-3 weeks to complete testing. If your testers are dedicated to non-stop testing with no time zone issues, it should only take about 2-3 days to complete. Testing Readiness for VPIMv2 Lucent (IMA-ML 1.x) - Now, Lucent (IMA-ML 2.x, Intuitity IMA-ESP) - 2Q 99 Lucent (Unified Messenger) - ??? Comverse (INF) - ? 99 Comverse (Access ANP) - 1Q 99 Active Voice (Unity) - ? 99 Nortel (CallPilot, MMNG, NVM) - Now Brite - 2Q 99 Technomen - ? 99 DCL - ? 99 Glenayre - ? 99 Others ? <> ---------- From: Bernard Elliot Sent: Thursday, February 25, 1999 11:57 am To: EMA,VPIM-L Subject: re: VPIM Directory - X.500/LDAP Orly, Current planning for the VPIM trials is based on LDAP v2. The inclusion of LDAP v3 will be considered when it is mature and participating companies feel that it should be supported. Unifi is planning to post an example directory for the trials shortly. So LDAP is sufficient. Useful directory background and references are on the ema web site at www.ema.org/vpimdir/directory. An example schema developed by Anne Brown is at ftp://ftp.isi.edu/internet-drafts/draft-ema-vpimdir-schema-00.txt. Bern Elliot elliot@acm.org ---------- Forwarded Message ---------- From: "Rappaport, Orly", INTERNET:Orly_Rappaport@icomverse.com TO: EMA, V Profile Inet Mail, INTERNET:vpim-l@ema.org DATE: 2/25/99 7:21 AM RE: VPIM Directory - X.500/LDAP I would appreciate your response to the following: To be a VPIM directory server which: 1. Provides LDAP access to VPIM compliant systems AND 2. Can integrate with other VPIM directories Is X.500 required or can LDAP server be sufficient? Thanks Orly Rapaport Comverse Network Systems Tel: +972-3-645.2658 (Fax: 2678) E-mail: orly_rapaport@comverse.com ---------- From: Rappaport, Orly Sent: Thursday, February 25, 1999 8:22 am To: vpim-l@ema.org Subject: VPIM Directory - X.500/LDAP I would appreciate your response to the following: To be a VPIM directory server which: 1. Provides LDAP access to VPIM compliant systems AND 2. Can integrate with other VPIM directories Is X.500 required or can LDAP server be sufficient? Thanks Orly Rapaport Comverse Network Systems Tel: +972-3-645.2658 (Fax: 2678) E-mail: orly_rapaport@comverse.com ---------- From: Michael.Wilson@Octel.com Sent: Thursday, February 25, 1999 5:39 am To: vpim-l@ema.org Subject: RE: VPIM v3 Codecs Redux Diego Besprovan wrote: > When you talk about GSM. you'r talking about the MS > implementation ( wav format 49 ) or the raw GSM 06.10 as > implemented by Jutta [HTTP] in the "toast" project. Because > the two implementations are diferent, written from the same > ETSI pseudocode, but ending up with imcompatible framing and > different code order in the bytes. > > I think that the MUST should be the 06.10 GSM raw > implementation as defined in [HTTP], there is an article in ... This is mixing up the audio coding with its wrapper. WAV-wrapped GSM audio *must* be in MS GSM 6.10 framing, as there is no other registered GSM WAV codec (to my knowledge). The "raw" (MIME-tagged) GSM need not, of course, use the MS framing. These matters (WAV vs MIME audio tag; MS vs. non-MS framing) should be considered independently. Having TWO GSM framings will probably displease many implementers. Michael Wilson Lucent OMD ---------- From: Diego Besprosvan Reply To: diegob@talkmail.com Sent: Thursday, February 25, 1999 5:40 am To: vpim-l@ema.org Subject: Re: VPIM v3 Codecs Redux Hi; When you talk about GSM. you'r talking about the MS implementation ( wav format 49 ) or the raw GSM 06.10 as implemented by Jutta [HTTP] in the "toast" project. Because the two implementations are diferent, written from the same ETSI pseudocode, but ending up with imcompatible framing and different code order in the bytes. I think that the MUST should be the 06.10 GSM raw implementation as defined in [HTTP], there is an article in Dr. Dobbs ( form Jutta ) that explains the implementation in more details. The source code is available from [HTTP]. The MS-GSM implementation will be supported like any other .wav encapsulation. [HTTP]=http://kbs.cs.tu-berlin.de/~jutta/toast.html. We wrote a pure Java implementation of the GSM codec ( supports the 2 versions ) that we use in the TalkM@il server. If someone want's to get it for test just send me an e-mail to diegob@mailvision.com. Jonathan Taylor wrote: > > >It's been quite a while, but I wanted to reply to Milt's message and see >if we have a consensus on the ideas he presented. > >The suggestion is to word the audio codec part of VPIM-3 as follows: > >1. Make GSM and G.726 MUST codecs >2. Make G.723.1, G.729a, and G.711 SHOULD codecs >3. For non-.WAV audio packaging, MAY support any codec registered with >the IANA >4. For .WAV audio packaging, MAY support any codec registered with >Microsoft > (need info on what "registered with Microsoft" means) >5. Senders MUST send in GSM or G.726 unless they explicitly know the >recipient supports another codec. >6. Mechanisms for how a sender explicitly knows the recepient supports >another codec are outside of the scope of VPIM-3. > >Personally I think this is a great proposal. We can follow up later >with standard mechanisms for senders to determine that recipients >support codecs other than G.726 or GSM; and in the meantime anyone can >send whatever they want as long as they know what's on the other end. > >Also, if anyone wants the free open source implementation of the GSM >codec just email me. > >-Jonatahan Taylor >-Chief Techology Officer >-MediaGate, Inc. ************************* * Diego Besprosvan * * CTO, Directo of R&D * * MailVision Ltd. * * diegob@mailvision.com * * http://mailvision.com * ************************* ******************************** Sent by TalkM@il Server mailto:info@mailvision.com http://mailvision.com ******************************** ---------- From: Jonathan Taylor Sent: Wednesday, February 24, 1999 10:01 pm To: Milt Roselinsky; vpim-l@ema.org Subject: VPIM v3 Codecs Redux It's been quite a while, but I wanted to reply to Milt's message and see if we have a consensus on the ideas he presented. The suggestion is to word the audio codec part of VPIM-3 as follows: 1. Make GSM and G.726 MUST codecs 2. Make G.723.1, G.729a, and G.711 SHOULD codecs 3. For non-.WAV audio packaging, MAY support any codec registered with the IANA 4. For .WAV audio packaging, MAY support any codec registered with Microsoft (need info on what "registered with Microsoft" means) 5. Senders MUST send in GSM or G.726 unless they explicitly know the recipient supports another codec. 6. Mechanisms for how a sender explicitly knows the recepient supports another codec are outside of the scope of VPIM-3. Personally I think this is a great proposal. We can follow up later with standard mechanisms for senders to determine that recipients support codecs other than G.726 or GSM; and in the meantime anyone can send whatever they want as long as they know what's on the other end. Also, if anyone wants the free open source implementation of the GSM codec just email me. -Jonatahan Taylor -Chief Techology Officer -MediaGate, Inc. Milt Roselinsky wrote: > > At 02:25 PM 1/8/99 +0000, Michael.Wilson@Octel.com wrote: > >Milt Roselinsky wrote: > > >> > >> If a vendor puts a product out in the market that doesn't let > >> the customer field update the codecs > >> supported, it will soon be selected against. > > > >I agree. Evolutionary pressure will fix what special interests won't. > > > >Backward compatibility with VPIM v2 requires that non-WAV encapsulation of > >G.726 must be supported, so for symmetry I would add non-WAV encapsulation > >of the WAV codecs (iff they have an IANA audio/xxxx content-type > >registered), and a WAV envcapsulation of G.726. > > > > I agree that both WAV encapsulation and non-WAV MIME encapsulation > MUST be supported, with the following wording: > > I propose that we only have codecs with no big licensing issues as MUST, > thus the list is: > MUST GSM, G.726 > > We then need a list of codecs that are VERY likely to be generally used: > SHOULD G.726, G.723.1, G.729a, G.711 > > Then the wording should be: > For non-WAV encapsulation, MAY support any codec registered with IANA. > For WAV encapsulation, MAY support any codec registered in Microsoft's WAV > documentation. > > Then there should be wording to the effect that if a voicemail system composing a VPIM v3 > message MUST send GSM or G.726 encoding unless it has knowledge that some other encoding > is likely to be supported at by the end system. Methods of knowing what encodings would > work is outside the scope of VPIM v3. > > Milt ---------- From: user@nt.com Sent: Wednesday, February 3, 1999 6:39 pm To: vpim-l@ema.org Subject: VPIM v2 Boot Camp <> Folks, Just a reminder about the VPIM boot camp on Thursday morning. See the website for the slides, white paper, and call in number: http://www.ema.org/vpimdir/conformance/bootcamp.html Cheers, Glenn. ---------- From: Graham Klyne Sent: Wednesday, February 3, 1999 10:10 am To: Parsons, Glenn [NORSE:6L45-I:EXCH] Cc: vpim-l@ema.org Subject: Re: Indicating Recipient Media Features for VPIM Glen, Your proposals seem very reasonable. I have a few comments which really are nits, and for the most part you may choose to ignore without any harm. As a general suggestion, it would probably be a good idea to check that you can effectively describe some real-life configurations at useful levels of detail. For the fax work, we were guided very much by the various TIFF profiles in RFC2301: our goal was to capture the details that can be expressed there without forcing agents to provide details that they didn't know or care about (especially in the area of colour repreduction). I can imagine some possible similar issues might arise in audio coding issues. At 00:38 03/02/99 -0500, Glenn Parsons wrote: [...] >3. VPIM feature tags > [...] > >3.1 Voice codec > > Feature tag name Legal values > ---------------- ------------ > codec G.726-32 > G.711-mu > G.711-a > G.729a > G.723.1 > GSM-6.10 > ...any more? Given that the IETF feature tag namespace (used here) can potentially cover a very wide range of different applications, would it be helpful to use the tag name 'audio-codec' here? Also, I note that the conneg syntax does not permit "." in token values, as used above. (To allow this would introduce an ambiguity into the grammar.) The allowed characters in a token are 'token = ALPHA *( ALPHA / DIGIT / "-" )'. I offer two alternative solutions: (a) use string values rather than tokens (i.e. the codec identifying tokens ae enclosed in quites, as "G.726-32", etc.). (b) delete periods in the token names, or replace them with '-' (e.g. "G726-32" or "G-726-32"). FWIW, faced with similar choices in the fax work, we simply removed the period; e.g. we have a token value defined by reference to T.85: image-coding-constraint=JBIG-T85 >3.2 Voice headers > > Feature tag name Legal values > ---------------- ------------ > codec-header None > WAV > AIFF > ASF > RA > ...more? In the fax work, we used a tag to describe a "file structure" rather than a "header format", so we have the tag: image-file-structure=TIFF-S etc. Would this be a more flexible approach than just defining a header format? (I am assuming that a header format is an implicit part of a file structure.) >3.3 UA Terminal type > > Feature tag name Legal values > ---------------- ------------ > ua-terminal fixed-handset > desktop > UM-desktop > modile-handset > Pager > ...more? A tag called 'ua-terminal' could have wider applicability than just audio devices. >3.4 Audio Channels > > Feature tag name Legal values > ---------------- ------------ > channels Mono > Stereo > ...more? Use tag name 'audio-channels'? What is the range of possible values here? Is it simply a number (i.e. n-channels), or is there a desire to capture other related information (e.g. surround-sound)? Not being an audio expert, the former seems more appropriate in which case I'd suggest making the feature value numeric (so I can send you my 8-track home recording?). >3.5 MIME audio content-types > > Feature tag name Legal values > ---------------- ------------ > mime-audio audio/32kadpcm > audio/wav > audio/basic > audio/gsm > audio/* > ..more? Here, you touch on an interesting issue that the conneg haven't fully resolved yet, though it has been discussed. One obvious capability of any recipient is the MIME types that it can accept. If we have a generic way to indicate MIME type handling capability then I don't think this tag would be needed. #g ------------ Graham Klyne (GK@ACM.ORG) ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Wednesday, February 3, 1999 1:38 am To: vpim-l@ema.org Subject: Indicating Recipient Media Features for VPIM Folks, Content negotiation is just about finished (see last call below). The Internet fax folks have worked hard to move this through and I think it has a lot of merit. I propose that VPIM v3 should include a section on capabilities that indicates that recipients SHOULD support requests for media features -- both the fax features from and the voice ones I've proposed below. I think this is important in order to determine capabiilties of the recipient (specifically codec support) beyond the minimum set. This information can be stored in a local directory, retrieved via LDAP or obtained using the MDN/DSN mechanism. (I'd say we should look at the DNS-based Mailcap work -- but they are just starting...) My initial proposal is just a simple list of features for voice messaging. This is based on by Graham Klyne & Lloyd McIntyre. I've made a first cut at only a new section 3 so far: 3. VPIM feature tags This section enumerates and briefly describes a number of feature tags that are defined for use with the Voice Profile for Internet Mail version 3 (VPIM v3) for voice messaging systems and applications. These tags may be used also by other systems and applications that support corresponding capabilities. The feature tags presented below are those that a VPIM v3 system is expected to recognize its ability or non-ability to handle. The values are listed with the default first. NOTE: The presence of a feature tag in this list does not mean that a VPIM v3 system must have that capability; rather, it must recognize the feature tag and deal with it according to the capabilities that it does have. Further, a VPIM v3 system is not prevented from recognizing and offering additional feature tags. The list below is intended to provide a minimum vocabulary that all VPIM v3 systems can use in a consistent fashion. If an unrecognized or unused feature tag is received, the feature set matching rule (described in [SYNTAX]) operates so that tag is effectively ignored. 3.1 Voice codec Feature tag name Legal values ---------------- ------------ codec G.726-32 G.711-mu G.711-a G.729a G.723.1 GSM-6.10 ...any more? 3.2 Voice headers Feature tag name Legal values ---------------- ------------ codec-header None WAV AIFF ASF RA ...more? 3.3 UA Terminal type Feature tag name Legal values ---------------- ------------ ua-terminal fixed-handset desktop UM-desktop modile-handset Pager ...more? 3.4 Audio Channels Feature tag name Legal values ---------------- ------------ channels Mono Stereo ...more? 3.5 MIME audio content-types Feature tag name Legal values ---------------- ------------ mime-audio audio/32kadpcm audio/wav audio/basic audio/gsm audio/* ..more? I'd appreciate your comments. Cheers, Glenn. > ---------- > From: The IESG > Reply To: iesg@ietf.org > Sent: Tuesday, January 12, 1999 1:36 PM > To: IETF-Announce > Cc: ietf-fax@imc.org > Subject: Last Call: Indicating Supported Media Features Using > Extensions to DSN and MDN to Proposed Standard > > > The IESG has received a request from the Internet Fax Working Group to > consider the following Internet-Drafts as Proposed Standards: > > > o Indicating Supported Media Features Using Extensions to DSN and MDN > > > o Content feature schema for Internet fax > > > o Extended Facsimile Using Internet Mail > > > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by January 26, 1999. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-fax-reporting-extensions-04 > .txt > http://www.ietf.org/internet-drafts/draft-ietf-fax-feature-schema-05.txt > http://www.ietf.org/internet-drafts/draft-ietf-fax-eifax-11.txt > > > ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Wednesday, February 3, 1999 1:38 am To: EMA,VPIM-L Subject: RE: VPIM Version 3 Goals (draft) Folks, Greg & I have revised VPIMv3 & the multipart registrations which you may have seen on the list (and soon in the ID archives). Laile also issued a Goals document to the list as well. Please bring a copy of these with you to the meeting as we will likely not make many copies of these. I'm sure many of you know my view by now, but here are a few comments (inspired by reading the Goals document put together by Laile): First of all, I still don't think we should add any more codecs without defining a capabilities negotiation mechanism so that we can determine what codecs the destination supports. The default codec must be sent if you know nothing about the recipient. I would contend that on sending, this one codec MUST be G.726. I would agree that on reception we should state MUST play G.726 and (maybe, if you twist my arm and repeat after me 'conservative in what you send and liberal in what you receive' :-) WAV GSM. I don't want to burden the VM serves with any transcoding matrices . However, we can say that systems MAY send or receive any WAV codecs or any audio/* iff (that's if and only if) they know the recipient can deal with it (via prior knowledge or capabilities negotiation). Also, I think we need to put the WAV codec in the parameters field of audio/wav to help VM systems. I contend that there will always be a better new codec that people want to use and most voice vendors (like it or not) use different proprietary codecs natively -- I don't see this changing soon. Transcoding is best avoided (especially multiple times). If this can be avoided (through prior knowledge) that is a good thing. Anyway, the mechanism that the Fax folks have settled on through Conneg is a good approach. I'll talk about that in another message. Secondly, I 'm not a fan of changing VPIM v2 to fit VPIM v3. There is a growing list of VM vendors that support VPIM v2 with service deployment by many large service providers expected this year. I am sure that we define VPIM v3 appropriately and with good interworking, without changing VPIM v2. Note that I do believe that VPIM v2 needs some clarifications as we move it from Proposed to Draft Standard. That brings me to my third point, VPIM v2 interoperability with VPIM v3 is critical and we must maintain this. VPIMv3 systems must be able to receive and play VPIM v2 messages. VPIM v3 systems MUST be able to create a VPIM v2 message. Fourth, the primary message content type is a very useful format. This conveys our requirements much better than a critical content parameter. The top level format can indicate what the the sender created the message as: email (multipart/mixed), voice message (multipart/voice-message) or fax message (multipart/fax-message). It can also be used by user agents in presenting the message as the sender intended (if the UA support this). Finally, we might as well start refering to DRUMS since it will be Internet Mail by the time we are done. Anyway, more on this during tomorrow morning's meeting. Feel free to call in if you can't attend in person. Cheers, Glenn. ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Tuesday, February 2, 1999 8:39 pm To: 'vpim-l@ema.org' Subject: Indicating Recipient Media Features for VPIM Folks, Content negotiation is just about finished (see last call below). The Internet fax folks have worked hard to move this through and I think it has a lot of merit. I propose that VPIM v3 should include a section on capabilities that indicates that recipients SHOULD support requests for media features -- both the fax features from and the voice ones I've proposed below. I think this is important in order to determine capabiilties of the recipient (specifically codec support) beyond the minimum set. This information can be stored in a local directory, retrieved via LDAP or obtained using the MDN/DSN mechanism. (I'd say we should look at the DNS-based Mailcap work -- but they are just starting...) My initial proposal is just a simple list of features for voice messaging. This is based on by Graham Klyne & Lloyd McIntyre. I've made a first cut at only a new section 3 so far: 3. VPIM feature tags This section enumerates and briefly describes a number of feature tags that are defined for use with the Voice Profile for Internet Mail version 3 (VPIM v3) for voice messaging systems and applications. These tags may be used also by other systems and applications that support corresponding capabilities. The feature tags presented below are those that a VPIM v3 system is expected to recognize its ability or non-ability to handle. The values are listed with the default first. NOTE: The presence of a feature tag in this list does not mean that a VPIM v3 system must have that capability; rather, it must recognize the feature tag and deal with it according to the capabilities that it does have. Further, a VPIM v3 system is not prevented from recognizing and offering additional feature tags. The list below is intended to provide a minimum vocabulary that all VPIM v3 systems can use in a consistent fashion. If an unrecognized or unused feature tag is received, the feature set matching rule (described in [SYNTAX]) operates so that tag is effectively ignored. 3.1 Voice codec Feature tag name Legal values ---------------- ------------ codec G.726-32 G.711-mu G.711-a G.729a G.723.1 GSM-6.10 ...any more? 3.2 Voice headers Feature tag name Legal values ---------------- ------------ codec-header None WAV AIFF ASF RA ...more? 3.3 UA Terminal type Feature tag name Legal values ---------------- ------------ ua-terminal fixed-handset desktop UM-desktop modile-handset Pager ...more? 3.4 Audio Channels Feature tag name Legal values ---------------- ------------ channels Mono Stereo ...more? 3.5 MIME audio content-types Feature tag name Legal values ---------------- ------------ mime-audio audio/32kadpcm audio/wav audio/basic audio/gsm audio/* ..more? I'd appreciate your comments. Cheers, Glenn. ---------- From: The IESG Reply To: iesg@ietf.org Sent: Tuesday, January 12, 1999 1:36 PM To: IETF-Announce Cc: ietf-fax@imc.org Subject: Last Call: Indicating Supported Media Features Using Extensions to DSN and MDN to Proposed Standard The IESG has received a request from the Internet Fax Working Group to consider the following Internet-Drafts as Proposed Standards: o Indicating Supported Media Features Using Extensions to DSN and MDN o Content feature schema for Internet fax o Extended Facsimile Using Internet Mail The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 26, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-fax-reporting-extensions-04.txt http://www.ietf.org/internet-drafts/draft-ietf-fax-feature-schema-05.txt http://www.ietf.org/internet-drafts/draft-ietf-fax-eifax-11.txt ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Tuesday, February 2, 1999 8:34 pm To: 'EMA,VPIM-L' Subject: RE: VPIM Version 3 Goals (draft) Folks, Greg & I have revised VPIMv3 & the multipart registrations which you may have seen on the list (and soon in the ID archives). Laile also issued a Goals document to the list as well. Please bring a copy of these with you to the meeting as we will likely not make many copies of these. I'm sure many of you know my view by now, but here are a few comments (inspired by reading the Goals document put together by Laile): First of all, I still don't think we should add any more codecs without defining a capabilities negotiation mechanism so that we can determine what codecs the destination supports. The default codec must be sent if you know nothing about the recipient. I would contend that on sending, this one codec MUST be G.726. I would agree that on reception we should state MUST play G.726 and (maybe, if you twist my arm and repeat after me 'conservative in what you send and liberal in what you receive' :-) WAV GSM. I don't want to burden the VM serves with any transcoding matrices . However, we can say that systems MAY send or receive any WAV codecs or any audio/* iff (that's if and only if) they know the recipient can deal with it (via prior knowledge or capabilities negotiation). Also, I think we need to put the WAV codec in the parameters field of audio/wav to help VM systems. I contend that there will always be a better new codec that people want to use and most voice vendors (like it or not) use different proprietary codecs natively -- I don't see this changing soon. Transcoding is best avoided (especially multiple times). If this can be avoided (through prior knowledge) that is a good thing. Anyway, the mechanism that the Fax folks have settled on through Conneg is a good approach. I'll talk about that in another message. Secondly, I 'm not a fan of changing VPIM v2 to fit VPIM v3. There is a growing list of VM vendors that support VPIM v2 with service deployment by many large service providers expected this year. I am sure that we define VPIM v3 appropriately and with good interworking, without changing VPIM v2. Note that I do believe that VPIM v2 needs some clarifications as we move it from Proposed to Draft Standard. That brings me to my third point, VPIM v2 interoperability with VPIM v3 is critical and we must maintain this. VPIMv3 systems must be able to receive and play VPIM v2 messages. VPIM v3 systems MUST be able to create a VPIM v2 message. Fourth, the primary message content type is a very useful format. This conveys our requirements much better than a critical content parameter. The top level format can indicate what the the sender created the message as: email (multipart/mixed), voice message (multipart/voice-message) or fax message (multipart/fax-message). It can also be used by user agents in presenting the message as the sender intended (if the UA support this). Finally, we might as well start refering to DRUMS since it will be Internet Mail by the time we are done. Anyway, more on this during tomorrow morning's meeting. Feel free to call in if you can't attend in person. Cheers, Glenn. ---------- From: Vinay.Gupta@centigram.com Sent: Tuesday, February 2, 1999 2:07 pm To: vpim-l@ema.org Subject: Remove Remove from the list ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Tuesday, February 2, 1999 6:08 am To: vpim-l@ema.org; ietf-fax@imc.org Subject: VPIMv3 unified messaging <> Folks, The attached draft is a part of the proposed VPIM v3 which takes a step closer to unified messaging. This draft adds the semantic of a primary message content type -- that is, what did the orginator create the multimedia message as (e.g., a voice message or a fax message). This is envisaged to help systems retain this intent in delivery and presentation. We discussed this in Orlando at the informal VPIM BOF where most people agreed with the proposal. We will discuss this draft initially at the EMA VPIM meeting this week and we look forward to comments. <> Cheers, Glenn. ---------- From: Parsons, Glenn [NORSE:6L45-I:EXCH] Sent: Tuesday, February 2, 1999 12:58 am To: 'vpim-l@ema.org'; 'ietf-fax@imc.org' Subject: VPIMv3 unified messaging Folks, The attached draft is a part of the proposed VPIM v3 which takes a step closer to unified messaging. This draft adds the semantic of a primary message content type -- that is, what did the orginator create the multimedia message as (e.g., a voice message or a fax message). This is envisaged to help systems retain this intent in delivery and presentation. We discussed this in Orlando at the informal VPIM BOF where most people agreed with the proposal. We will discuss this draft initially at the EMA VPIM meeting this week and we look forward to comments. <> Cheers, Glenn. ---------- From: Bernard Elliot Sent: Monday, February 1, 1999 2:57 pm To: EMA,VPIM-L Subject: Inter-Company Voice Messaging - Meeting Notes Preparation Notes Inter-Company Voice Messaging: Blueprint for Practices and Agreements An EMA Voice Messaging Committee Work Group January 26, 1999 B.Elliot elliot@acm.org This message provides preliminary notes on topics that will be discussed by the Inter-Company Voice Messaging work group starting on February 3d. This document provides a place to start discussion and represents one initial view of how we might address these issues. This message contains notes on the following topics: 1. High-level architecture and agreement assumptions 2. Directory & addressing 3. VPIM (and other) standards conformance agreement. 4. Governance, Grievances, & Policy 5. Costs & settlements 6. Service quality and levels 7. Relationship to other messaging media. 8. Enterprise administrator