One document matched: draft-burger-imap-chanuse-01.txt
Differences from draft-burger-imap-chanuse-00.txt
Network Working Group E. Burger
Internet Draft SnowShore Networks, Inc.
Document: draft-burger-imap-chanuse-01.txt November 3, 2002
Category: Informational
Expires: April 2002
IMAP CHANNEL Use Cases
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Discussion of this and related drafts are on the LEMMONADE list. To
subscribe, send the message "subscribe um" to
majordomo@snowshore.com .
Abstract
This document describes different use cases for using the IMAP
CHANNEL facility.
Burger Informational - Expires April 2003 1
CHANNEL Use Cases November 2002
Table of Contents
1. Conventions used in this document..................................2
1.1. Definitions......................................................2
1.1.1. Keywords.......................................................2
1.1.2. Jitter.........................................................3
1.1.3. Latency........................................................3
1.1.4. Real-Time Stream...............................................3
1.1.5. IMAP Store.....................................................3
1.1.6. Client Device..................................................3
1.1.7. Media Server...................................................3
2. Use Cases..........................................................3
2.1. Conventional Message Store in Real-Time Network..................3
2.2. Clients Configured With "Close" Hosts............................4
2.3. Transcoding Service..............................................6
2.4. Mail Sending service.............................................7
3. Security Considerations............................................8
4. References.........................................................9
5. Contributors......................................................10
6. Acknowledgments...................................................10
7. Author's Address..................................................10
1. Conventions used in this document
This document refers generically to the sender of a message in the
masculine (he/him/his) and the recipient of the message in the
feminine (she/her/hers). This convention is purely for convenience
and makes no assumption about the gender of a message sender or
recipient.
FORMATTING NOTE: Notes, such at this one, provide additional
nonessential information that the reader may skip without missing
anything essential. The primary purpose of these non-essential
notes is to convey information about the rationale of this document,
or to place this document in the proper historical or evolutionary
context. Readers whose sole purpose is to construct a conformant
implementation may skip such information. However, it may be of use
to those who wish to understand why we made certain design choices.
1.1. Definitions
1.1.1. Keywords
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
Burger Informational - Expires April 2003 2
CHANNEL Use Cases November 2002
1.1.2. Jitter
Jitter is the variation of inter-arrival times for a packet stream.
Say a source generates a stream at a constant rate, such as one
packet every 20ms. Then the jitter is the variation away from 20ms
per packet from the packet inter-arrival time at the destination.
1.1.3. Latency
Latency is the amount of time a packet takes to transit an
operation. An operation can be transport, such as the terrestrial
transmission delay and router queue delays. An operation can also
be transformation, such as transcoding a stream from one format to
another or mixing a set of streams to create a new stream.
1.1.4. Real-Time Stream
A real-time stream is a packet flow characterized by having hard
requirements for latency, jitter, or both. For example, a
unidirectional voice flow requires almost no jitter. A bi-
directional voice flow requires almost no jitter and an end-to-end
latency of ideally less than 150ms and absolutely less than 200ms.
1.1.5. IMAP Store
An IMAP Store is a repository for messages accessed by the IMAP
protocol.
1.1.6. Client Device
A client device is a device that presents messages to the user.
1.1.7. Media Server
A media server is a device that transforms or adapts media (audio or
video) into an appropriate format for a client device.
2. Use Cases
2.1. Conventional Message Store in Real-Time Network
Conventional message stores typically run on general-purpose
computing hardware. Such platforms are very good at general storage
management and the data base management needed for keeping track of
user's profiles and messages. In addition, most general-purpose
computing platforms are rather efficient at retrieving large disk
Burger Informational - Expires April 2003 3
CHANNEL Use Cases November 2002
blocks and transmitting and receiving relatively large network
packets (e.g. 8KB blocks).
For a variety of architectural reasons, general-purpose platforms
are rather inefficient for streaming low-latency, low-jitter
streams. Not only is the jitter unpredictable, the number of
simultaneous streams such a platform can support may be unacceptably
small.
The IMAP CHANNEL facility allows the network a mechanism for serving
IMAP messages with real-time delivery constraints. Here is an
exemplary configuration.
imap.sp.net
+---------+
IMAP | IMAP |
+--------+ ------------------------------>| Store |
| Client |/ ms.sp.net +---------+
| Device |<---\ SIP +--------+ ^
+--------+ \=============| Media | __| HTTP
| Server |---/
+--------+
In this example, the client issues a request to the IMAP store for
an object. The client knows that it needs real-time playback. The
client can know this, for example, if it knows the object is a
multimedia object. The client can determine this by convention
(e.g., the only message types stored are multimedia objects) or from
examining the content-type of the body part. Since the client
requires real-time playback of the object, it issues an IMAP CHANNEL
request, requesting an appropriate protocol, such as SIP [4] or RTSP
[5], for control of the object transport. In the example above, the
client asks for a SIP stream by issuing the following IMAP CHANNEL
request.
C: 927 CHANNEL (sip:) (2 3.2)
This requests the server to fetch section 3.2 from message 2. The
client requests SIP as the return mechanism.
The server responds with a URI that is opaque to the client. Here
is an example using SIP netann [6].
S: * 1 CHANNEL 2
sip:annc@ms.sp.net;play=http://imap.sp.net/cgi-bin/get-obj?1af4e92
S: 927 OK done
2.2. Clients Configured With "Close" Hosts
Clients, such as 3G wireless mobile terminals, can retrieve RTSP,
but may have limitations on which servers they can communicate with.
Burger Informational - Expires April 2003 4
CHANNEL Use Cases November 2002
Likewise, the client may have a preferred set of hosts. Here is an
exemplary configuration.
+-------------+
| imap.sp.net |
| IMAP |
| Store |
+-------------+
+--------+ +--------------+
| Client | | close.sp.net |
| Device | | Close | +---------------+
+--------+ | Media | | far.other.com |
| Server | | Very |
+--------------+ | Far |
| Media |
+------------+ | Server |
| far.sp.net | +---------------+
| Far |
| Media |
| Server |
+------------+
In this example, the client issues a request to the IMAP for the
object. The client, through means outside IMAP, knows the
"distance" to the relevant media servers. The client issues the
following IMAP CHANNEL request.
C: 1023 CHANNEL (rtsp://close.sp.net
rtsp://far.sp.net
rtsp: imap:) (2 3.2) (9 1) (11 4.5)
This requests the server to fetch section 3.2 from message 2,
section 1 from message 9, and section 4.5 from message 11, with the
preferred order of servers for retrieving the object. Note the
listing of the partial-URI is for readability. An actual request
would have a space-separated list.
The server responds with (a set of) URI. Here is an example
response.
S: * 2 CHANNEL 3.2 rtsp://far.sp.net/playback/431987
S: * 9 CHANNEL 1 rtsp://close.sp.net/v531hn034f
S: * 11 CHANNEL 4.5 rtsp://far.other.com/m11p4e5.gsm \
rtsp://imap.sp.net/m11p4e5.au
S: 1023 OK done
The first response shows that the server could not satisfy the
request at the close media server, but could at the far one. The
second response shows that the server could satisfy the request from
the close media server. The third response show a copy available in
Burger Informational - Expires April 2003 5
CHANNEL Use Cases November 2002
another domain and a copy on the IMAP server itself. Note that the
determination of whether to send a list or not is up to the IMAP
server.
2.3. Transcoding Service
Often, the object media type in the message store is different than
what the user device can display. For example, MS-GSM is a
convenient audio format for unified messaging systems, as it is
relatively compact, has decent audio quality, and is ubiquitous.
However, MS-GSM is not a good audio format for telephony devices.
Telephony devices such as mobile phones expect GSM; long distance
networks expect G.726; voice-over-IP network may expect G.729ab; and
enterprise gateways expect G.711.
In addition, objects may need transformation. For example, one may
wish to access a 1000x1000 pixel image that is in a high-fidelity
format, such as a 600 dpi bitmap in 16-bit color. However, the
user's device may only be able to display 320x320 pixel PNG at 72
dpi resolution in 8-bit color. Note the former image is around 16
Mb, while the latter image is well under 1Mb. For high-latency
networks, this difference in object size is significant.
Thus, there is a need to transcode objects from one format to
another.
The OPES work group [7] is addressing the general case for object
transformation. Simply requesting an http: URL that an OPES server
will intercept will cause the appropriate transformation to occur.
The following is an example of transparent, OPES transcoding. For
more detailed examples, see [8].
+---------+ IMAP +--------+
| User |--------------------------------->| IMAP |
| Device |--\ | Store |
+---------+ \ +--------+
|| \http ^
|| \ +--------+ ----------|
|| \->| OPES | /
|| | Server | /
|| +--------+ /
|| | /
|| Media |ocp / Fetch
|| (e.g., GSM-AMR) v / (e.g., NFS, IMAP)
|| +--------+ / (e.g., MS-GSM)
================| Media |--/
| Server |
+--------+
Burger Informational - Expires April 2003 6
CHANNEL Use Cases November 2002
In addition, the client can directly request transcoding services
from the media server. In the following example, the client
requests a SIP media stream. The IMAP store returns a SIP URI that
indicates a request for a transcoding service. Here is an example
request flow.
C: 1023 CHANNEL (sip:) (7)
S: * 7
sip:annc@ms.sp.net;play=file://store.sp.net/msgs/412.wav
In this example, the transcoding request is implicit. The file is
self-describing (a WAVE file), and the media the user device wants
to receive the message in gets negotiated in the normal SIP offer-
answer negotiation.
2.4. Mail Sending service
Often clients may wish to send a message through SMTP that exists in
the IMAP store without downloading the message to the client first.
One can do this by using a "mailto:" URL with the CHANNEL command.
The addresses provided in the "mailto:" URL are the SMTP envelope
recipients to which the message store is to send the message. The
common case would be as follows:
C: 0 CHANNEL (mailto:burger@example.com) (5)
This requests the server to send all of message 5 to the address
"burger@example.com" via SMTP [9]. The store sends the message as
it is in the IMAP store. The store MUST NOT change either the
message's contents or its headers. This is so clients may send
messages to users without revealing their addresses in the header of
the message (as is done using empty groups in the destination
addresses or sending blind carbon copies). However, if the
"mailto:" URL specifies header names, these may be prepended to the
message before it is sent. For example:
C: 1 CHANNEL (mailto:resnick@example.com?
resent-from=burger@example.net&
resent-to=resnick@example.com) (6)
The above would request that message 6 be sent to
resnick@example.com" with the following header fields prepended to
the message:
Resent-From: burger@example.net
Resent-To: resnick@example.com
This is quite useful for implementing a "Resend" service in a
client, where the client wants to send an exact copy of a previously
received message to somewhere else with only the resent trace fields
prepended to the message.
Burger Informational - Expires April 2003 7
CHANNEL Use Cases November 2002
The preceding uses of CHANNEL also apply if a part of a message is
specified in the channel-set that has a MIME type of
"message/rfc822". However, if a part is specified in the channel-
set that is not "message/rfc822", then the message is sent with the
top-level MIME type the same as the part specified. If multiple
parts are specified in the channel-set (even if one or more of them
are entire messages or parts of type "message/rfc822"), all of those
parts are sent together as a single "multipart/mixed" message. For
both of these cases, the client MUST specify any RFC 2822 header
fields it desires for the message in the URL; the MIME header fields
(such as "Content-Type:" and "Content-Transfer-Encoding:") for the
message will be provided by the server before sending the message.
For example:
C: 1 CHANNEL (mailto:resnick@example.com?
to=Pete%20Resnick%20<resnick@example.com>&
from=Eric%20Burger%20<burger@example.net>&
date=21%20Sep%202002%2010%3A29%3A00%20-0500)
(7)(8 1)(9 5.2)
The above will send a message with header fields similar to these:
To: Pete Resnick <resnick@example.com>
From: Eric Burger <burger@example.net>
Date: 21 Sep 2002 10:29:00 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=...
Content-Transfer-Encoding: 7bit
The header will be followed by message 7 as a part with a MIME type
of "message/rfc822", then part 1 of message 8 with its own MIME
type, and finally part 5.2 of message 9, again with its own MIME
type (all of course with the appropriate MIME boundary and Content-
Transfer-Encoding).
Note: The use of "mailto:" specified in this document
differs slightly from the definition in RFC 2368. Unlike
RFC 2368, mailto:resnick@example.com is *not* equivalent
to mailto:?to=resnick@example.com in the case of the
CHANNEL command. The former sends the message to
"resnick@example.com". The latter prepends a "To:
resnick@example.com" field to the message (and in this
particular example, sends to no one since there is no
destination address specified).
3. Security Considerations
Security will be a very important part of unified messaging. In
addition to the security issues present in Internet Mail, people
have higher expectations for Voice and Fax messaging. The goal,
wherever possible, is to preserve the semantics of existing
Burger Informational - Expires April 2003 8
CHANNEL Use Cases November 2002
messaging systems and meet the expectations of users with respect to
security and reliability.
The mailto: mechanism can be used to send e-mail via SMTP. This has
some of the same security implications as specified in RFC 2821,
section 7.
4. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
INFORMATIVE
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
NORMATIVE
3 Hole, S., Nerenberg, L., and Leiba, B., "IMAP4 Channel Transport
Mechanism", draft-nerenberg-imap-channel-02.txt, June 2002, work
in progress
NORMATIVE
4 J. Rosenberg, et. al., "SIP: Session Initiation Protocol", RFC
3261, June 2002.
NORMATIVE
5 Schulzrinne, H., Rau, A., and Lanphier, R., "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998
INFORMATIVE
6 Van Dyke, J., Burger, E. (Ed.), Spitzer, A., and O'Connor, W.,
"Basic Network Media Services with SIP", draft-burger-sipping-
netann-01.txt, November 2002, work in progress
INFORMATIVE
7 Barbir, A. et. al., "An Architecture for Open Pluggable Edge
Services (OPES)", draft-ietf-opes-architecture-03.txt, August
2002, work in progress
INFORMATIVE
8 Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H., and
Penno, R., "OPES Use Cases and Deployment Scenarios", draft-ietf-
opes-scenarios-01, August 2002, work in progress
INFORMATIVE
9 Klensin, J. (ed.), "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
NORMATIVE
Burger Informational - Expires April 2003 9
CHANNEL Use Cases November 2002
5. Contributors
Pete Resnick supplied the CHANNEL protocol machinery, as well as the
mailto: use case. However, any transcoding errors are my own.
6. Acknowledgments
I would like to thank Greg Vaudreuil and Glen Parsons for convincing
me this is a worthwhile effort. Also to Lyndon Nerenberg for
reminding me to get this draft out!
Alexey Melnikov found some typographic errors and helped start the
discussion on URI specifications.
7. Author's Address
Eric Burger
SnowShore Networks, Inc.
285 Billerica Rd.
Chelmsford, MA 01824-4120
USA
Phone: +1 978/367-8400
Email: eburger@snowshore.com
Burger Informational - Expires April 2003 10
CHANNEL Use Cases November 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
The Internet Society currently provides funding for the RFC Editor
function.
SnowShore Networks, Inc. is a member of The Internet Society.
Burger Informational - Expires April 2003 11
| PAFTECH AB 2003-2026 | 2026-04-23 09:46:40 |