Stuart McRae (stuart.mcrae@uk.ibm.com)
Tue, 20 Nov 2001 17:59:44 +0000
When I was revising the IVM draft I started work on an appendix on Gateway
Considerations for an IVM/VPIM v2 Gateway.
As I worked on it, it became more of a list of functions that a Gateway
needed to provide.
However, as that progressed I started to worry that is was repeating a lot
of the stuff that is already in the VPIMv2 spec. - which is not a good
thing (they could easily end up contradicting each other if we are not
careful, and it would be a lot of work to ensure completeness).
Anyway, the list as it currently exists is below, and the question now is:
What do we want to do with it?
We could tidy it up and include it in the IVM document as an appendix,
like I originally intended. If we do, I think it should be rephrased and
simplified more as a "list of things to worry about" and the user should
be referred to the VPIM v2 spec. for the details of what they have to do.
Alternatively, if we think the more detailed list is valuable, then it
should probably be issued as an Implementer's Guide. We could add more
guidelines in there - especially on the topic of translating between VPIM
v2 addresses and generic e-ail addresses. I am happy to be a co-author on
that, but as I am not building a Gateway which would confirm that the
issue areas are the correct ones and any recommendations are the right
ones, I feel neither motivated for competent to drive this.
Please let us know what you think.
Glenn, can you put this on the agenda for SLC (oops, missed the deadline -
well, as a topic for Any Other Business). I won't be there, but it would
be good to have the topic discussed (and perhaps a volunteer identified
;-)
Regards,
Stuart
14 Appendix A - Gateway Rules for IVM and VPIM v2
A gateway from VPIM v2 to IVM needs to address the following issues:
-------------------------------------------------------------------
* The destination address of a VPIM v2 message will typically be a
telephone number according to some numbering plan. The gateway is
responsible for mapping that through to an e-mail address (unless the
recipient IVM user is addressable via the telephone number address alias
form directly, or the originating system has already provided a full
e-mail address for the recipient). A mechanism such as that specified by
ENUM, or an LDAP directory, MAY be used for this purpose (see [VPIMENUM]
and [SCHEMA] for more information).
* The gateway SHOULD populate the "To:" and "CC:" header fields with an
appropriate version of the address of all of the recipients of the message
to allow any reply to be routed correctly to both VPIM v2 and non-VPIM v2
recipients in those lists. Only VPIM v2 recipients MUST be routed back
through the gateway - e-mail recipients MAY be routed directly.
* If the originator address for a VPIM v2 message is
""non-mail-user@domain" the gateway MUST ensure that any replies to that
user are rejected back to the user.
* The gateway MAY report any processing faults and exceptions to the
""postmaster@domain" address on the VPIM v2 system.
* The gateway SHOULD add a "Received:" field detailing information about
the system from which the message was received.
* The gateway SHOULD update the "MIME-Version:" field to remove the
"(Voice 2.0)" suffix, since this is no longer a VPIM v2 message.
* If the message includes a "Sensitivity" of "Private" the message MUST be
rejected with a negative delivery status notification 5.6.0 ("Other or
undefined protocol status") indicating that privacy could not be assured,
together with the original message contents, unless the recipient is known
to implement and respect the Sensitivity field requirements specified in
VPIMv2. Handling requirements for Sensitivity values of "Personal" and
"Company-Confidential" are a local matter for the gateway.
* The content type of multipart/voice-message MUST be relabelled
multipart/mixed, unless the recipient supports VPIM v2.
* All audio/32KADPCM voice body parts in the message MUST be transcoded
from G.726 to either MS-GSM in WAV or G.711 Mu-Law and given a new content
type of "audio/wav; codec=31" or "audio/basic", as appropriate, unless the
recipient is know to be able to support audio/32KADPCM.
* Any Image/TIFF Fax Contents must be converted to conform to RFC 2532
[IFAX]. [EDITORS NOTE: I have not yet considered what, if anything, this
entails]
* On the VPIM v2 side, ESMTP must be supported, including SIZE and DSNs.
ENHANCEDSTATUSCODES and PIPELINING SHOULD be supported. CHUNKING and
BINARYMIME MAY be supported. If these ESMTP features are not also
supported on the IVM side, then they should be downgraded in the
appropriate manner.
A gateway from IVM to VPIM v2 needs to address the following issues:
-------------------------------------------------------------------
* The destination address for a VPIM v2 message must be a telephone number
according to some numbering plan. The gateway is responsible for mapping
the destination e-mail address to such a VPIM address (unless the original
IVM recipient address is already in this format, or the target VPIM v2
system supports alphanumeric e-mail aliases). A mechanism such as that
specified by ENUM, or an LDAP directory, MAY be used for this purpose (see
[VPIMENUM] and [SCHEMA] for more information).
* An messages to be sent to "* An messages to be sent to "non-mail-user@domain" MUST be rejected back
to the sending user.
* The gateway MAY report any processing faults and exceptions to the
""postmaster@domain" address on the VPIM v2 system.
* The VPIM v2 system will send any replies to the "From:" field in the
header, so this addresses MUST be set correctly route replies via the
gateway to the originator. A valid "Reply-To:" field MAY be converted to
an appropriate VPIM v2 form and passed through, but note that a VPIM v2
system is likely to discard this in favour of the "From:" address.
* The VPIM v2 system will send any error messages to the address in the
ESMTP "MAIL FROM" field or the "Return-Path:" header field, so these
addresses MUST be set correctly to either let replies flow directly back
to the originator, or to flow back via the gateway. The gateway MUST
therefore maintain the "MAIL FROM field, but is only responsible for
populating the "Return-path:" if it is the last SMTP server before the
VPIM v2 system.
* The "To:" and "CC:" header fields SHOULD enumerate all of the recipients
for a message, as valid VPIM v2 addresses that can be used for a "reply
all" (either directly, if the user is also on a VPIM v2 system, or via the
gateway for IVM recipients). If the gateway cannot do this for all
recipients (e.g. does not have VPIM v2 aliases for all of the recipients
of the e-mail) then the "To:" and "CC:" fields SHOULD NOT be populated
(and in any case MUST NOT contain any invalid addresses).
* A "Date:" field MUST be provided, reflecting as accurately as possible
the time and date the message was created.
* A unique "Message-id" MUST be generated if one is not present.
* The gateway SHOULD add a "Received:" field detailing information about
the system from which the message was received.
* The gateway MUST generate a "MIME-Version:" field containing "1.0 (Voice
2.0)".
* The contents of the message MUST be reconstructed as a message with a
high level content type of multipart/voice-message. The gateway MAY also
pass messages with a top level content type of multipart/mixed through,
providing the contents of the message are still processed according to the
rules below.
* A "Content-Description" MAY be added to indicate that this message came
through the gateway.
* The gateway MUST preserve and "Content-Disposition", "Content-Duration"
or "Content-Language" information associated with the body parts. It MAY
calculate the "Content-Duration" for audio body parts and add them to the
message, if it wishes.
* The gateway MAY add additional body parts, such as the originator's
Spoken Name or a text to speech rendered Spoken Subject to the messages it
processes. If it does it should use the "Content-Disposition" to suppress
these attachments if they are already present, and it identify them if
they have been added.
* Any Fax Contents (represented according to RFC 2532 [IFAX]) MUST be
converted to Image/TIFF in accordance with the VPIM V2 specification. This
may involve converting the image to TIFF-F.
* When processing the following rules, message/RFC822,
multipart/voice-message, and (if supported) multipart/mixed messages are
handled recursively, analysing all of their contents according to the
following rules.
Messages containing any body parts with a Content Type of Text/Directory
or Text/Plain, the gateway MAY pass them through, silently drop them, or
reject the message, at its own choice (the latter is not in conformance
with VPIM v2 handling for Text/Plan, but reflects the fact that a message
gatewayed from e-mail may well have critical content in the plain text, so
informing the originator is better than dropping the content).
Messages containing a body part with a Content Type identifying a
proprietary audio or fax codec which the gateway knows that the target
VPIM v2 system supports MAY be passed through.
Messages containing body parts with any Content Types other than
Audio/32KADPCM, Image/TIFF, and those handled under the rules above, which
have a Content Disposition of CRITICAL, MUST be rejected (please note that
CRITICAL is the default value for the criticality of a message).
Messages containing any Content Types that cannot be handled according to
the rules above but with a Content Disposition of IGNORE, MUST have those
body parts silently dropped.
The only exception to the above rules is if the gateway knows that the
target VPIM v2 system can handle additional content types, which can then
be included in the message.
* The gateway MUST pass through DSNs and MDNs according to standard
processing rules.
* On the VPIM v2 side, ESMTP must be supported, including SIZE and DSNs.
ENHANCEDSTATUSCODES and PIPELINING SHOULD be supported. CHUNKING and
BINARYMIME MAY be supported. If these ESMTP features are not also
supported on the IVM side, then they should be downgraded in the
appropriate manner.
Stuart
This archive was generated by hypermail 2.0b3 on Tue Nov 20 2001 - 20:01:43 IST