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