doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc4024.txt b/doc/rfc/rfc4024.txt
new file mode 100644
index 0000000..ea93db0
--- /dev/null
+++ b/doc/rfc/rfc4024.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                         G. Parsons
+Request for Comments: 4024                               Nortel Networks
+Category: Informational                                      J. Maruszak
+                                                               July 2005
+
+
+                   Voice Messaging Client Behaviour
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines the expected behaviour of a client to various
+   aspects of a Voice Profile for Internet Mail (VPIM) message or any
+   voice and/or fax message.
+
+Table of Contents
+
+   1.  Introduction..................................................  2
+   2.  Conventions Used in This Document.............................  2
+   3.  Message Icon..................................................  3
+       3.1.  Proposed Mechanism......................................  3
+   4.  Sender's Number Column........................................  3
+       4.1.  Proposed Mechanism......................................  4
+   5.  Message Size..................................................  4
+       5.1.  Proposed Mechanism......................................  4
+   6.  Media Viewer..................................................  5
+       6.1.  Proposed Mechanism......................................  6
+   7.  Mark Message as Read..........................................  6
+       7.1.  Proposed Mechanism......................................  6
+   8.  Security Considerations.......................................  7
+   9.  Informative References........................................  7
+   10. Acknowledgments...............................................  8
+
+
+
+
+
+
+
+
+
+
+Parsons & Maruszak           Informational                      [Page 1]
+
+RFC 4024            Voice Messaging Client Behaviour           July 2005
+
+
+1.  Introduction
+
+   As Internet messaging evolves into unified messaging, the term
+   "e-mail" no longer refers to text-only messages.  Today's "e-mail"
+   are often multi-media.  That is, they can have numerous non-text
+   parts.  These parts can be attachments or can contain voice and/or
+   fax.
+
+   Each of voice, fax, and text have their own distinct characteristics,
+   which are intuitive to the user.  For example, each of these message
+   types require a different media viewer (text editor for text, audio
+   player for voice, and image viewer for fax), and the dimensions of
+   message size are also different for all three (kilobytes for text,
+   seconds for voice, and pages for fax).  As a result, a message that
+   includes more than one of these in its parts is termed a mixed media
+   message.
+
+   How the messaging client responds to, and acts on these differences
+   is termed "Client Behaviour".  This is dependent on the concept of
+   "Message-Context" [2] (previously called primary content), which
+   defines whether the message is a voice mail, fax, or text message.
+   The client can utilize this header to determine the appropriate
+   client behaviour for a particular message.
+
+   Traditionally, a messaging "client" referred to some sort of visual
+   interface (or GUI - graphical user interface) that was presented on
+   the users computer.  However, as messaging evolves to unified
+   communications the actual form of the messaging client is expected to
+   change.  Today's email can often be viewed on wireless devices with
+   very limited screens or even "viewed" over a telephone (i.e.,
+   listening to email as you would listen to voice mail through a TUI -
+   telset user interface).
+
+   The intent of this document is to be general and refer to all types
+   of messaging clients, as the user's expectation of behaviour based on
+   the type of message is not expected to change.  However, some of the
+   following concepts may tend towards the more common GUI client.
+
+2.  Conventions Used in This Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+   The key words "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 [4].
+
+
+
+
+
+Parsons & Maruszak           Informational                      [Page 2]
+
+RFC 4024            Voice Messaging Client Behaviour           July 2005
+
+
+3.  Message Icon
+
+   The preferred method to distinguish between voice, fax, and text
+   messages on a GUI client is with a visual cue, or icon.  A similar
+   voice prompt or "earcon" would be used for TUI clients.
+
+   As it is possible for the message to contain more than one media
+   type, the icon should describe the primary message content, as
+   defined by the "Message-Context" header.  Obvious choices for the
+   icon/message pairs would be a telephone for a voice message, a fax
+   machine for a fax message, and an envelope for a text mail message.
+   Similarly obvious for the earcons would be short spoken prompts like
+   "voice message".
+
+   This could be taken a step further, and have the GUI icon change to
+   indicate that the message has been read as is currently done in some
+   email clients (others do not change the icon but merely bold the
+   message in the message list to indicate it is unread).  For example,
+   a telephone with the receiver off-hook could indicate that the voice
+   message has been played.  A fax machine with paper at the bottom, as
+   opposed to the top, would show that the fax had been viewed.
+   Finally, an open envelope indicates that a text message has been
+   read.
+
+3.1.  Proposed Mechanism
+
+   As the choice of icon is determined by the primary message type, the
+   client should obtain this information from the "Message-Context "
+   message header.  This header is defined in [2].
+
+4.  Sender's Number Column
+
+   As is the case with most email GUI clients today, important message
+   information is organized into columns when presented to the user in a
+   the summary message list.  TUIs often present even briefer summaries
+   to the user at the beginning of the session.  Typical columns in the
+   GUI client include the message subject, and the date the message was
+   received.
+
+   Another important piece of information for the user is the origin of
+   the message.  For a voice or fax message, the origin is typically a
+   telephone or fax machine respectively, each of which has an
+   associated telephone number.  This telephone number is critical to
+   the user if they wish to return the call.  This should be presented
+   accurately to the user (without making it an email address).
+
+
+
+
+
+
+Parsons & Maruszak           Informational                      [Page 3]
+
+RFC 4024            Voice Messaging Client Behaviour           July 2005
+
+
+4.1.  Proposed Mechanism
+
+   Instead of forcing the telephone number into an email address, a new
+   Internet message header can be used to hold the originating telephone
+   number [3].  If the message is indicated as being a voice or fax
+   message per [2], the client should extract the number, and display it
+   to the user in a separate column.  As this header is defined to only
+   hold the digits of the telephone number, it is left to the client to
+   add any separating characters (e.g., "-").
+
+5.  Message Size
+
+   In the cases of large attachments, small clients (e.g., PDA) and slow
+   links (e.g., wireless) there is also a need for the client to see the
+   length of the message in a suitable format before opening it.
+
+   Currently, message size is normally given in kilobytes (kB).  This
+   is sufficient for plain text messages, but while it may give a hint
+   as to how good the compression algorithm is, kB is not very useful in
+   knowing the size of a voice and/or fax message.  Instead, the size
+   should give an indication of the length of the message, i.e., the
+   duration (in seconds) of a voice message, and the number of pages of
+   a fax.  Again, the message may contain multiple types, so the size
+   displayed should be that of the primary content type, per [2].
+
+5.1.  Proposed Mechanisms
+
+   There are three suggested methods to relay this information, of them,
+   the first method is favored:
+
+5.1.1.  MIME Header Content-Duration as described in RFC 2424 [5]
+
+   For voice messages, the Content-Duration field of the main audio/*
+   body part (as indicated by content-disposition per [1]) should be
+   displayed as the length of the message.  If there are several audio
+   parts, an implementation may display the message size as an aggregate
+   of the length of each.
+
+   For fax messages a new MIME Header, Content-Page-Length, could be
+   defined, similar to Content-Duration with the exception that number
+   of pages would be specified, rather than number of seconds.  (e.g.,
+   Content-Page-Length:3).  This would be created at origination.
+
+
+
+
+
+
+
+
+
+Parsons & Maruszak           Informational                      [Page 4]
+
+RFC 4024            Voice Messaging Client Behaviour           July 2005
+
+
+5.1.2.  Message length indicated as a parameter of an Existing
+        RFC 2045 [7] Content-Type Header Field
+
+   This would be created at the source.  This proposed method would
+   allow the message length to be passed to the client by default in
+   IMAP.  Again the client would have to choose between the main voice
+   message length or an aggregate message length for display.
+
+   Content-Type Header Field example:
+
+   Content-Type=audio/*; length=50
+   Content-Type=image/tiff; pages=3
+
+5.1.3.  Message length indicated as part of an existing RFC 2822 [9]
+        Header Field
+
+   This field would be created at the source and may include message
+   length information, but because it is part of the message headers, it
+   could also be amended on reception (by a local process).  This method
+   would allow the message length to be passed to any client by default
+   and not require any client modification.  If used, this field would
+   indicate the aggregate length of all attachments.
+
+   The advantage of this mechanism is that no new headers are required
+   and it works with existing clients.  The downside is that it
+   overloads the subject field.
+
+   Subject Header Field example:
+
+   Subject=Voice Message (0:04)
+   Subject=Fax Message (3p)
+   Subject=Voice Message (0:14) with Fax (1p)
+
+6.  Media Viewer
+
+   When a message is initially opened, the client should, by default,
+   open the proper media viewer to display the primary message content.
+   That is, an audio player for voice messages, an image viewer for fax,
+   and a text editor for text messages.  Note that on a TUI, the viewer
+   would render the media to sound (which would have varying effect
+   depending on the media and available process).
+
+   Where there is more than one body part, obviously the appropriate
+   viewer should be used depending on which body part the user has
+   selected.
+
+
+
+
+
+
+Parsons & Maruszak           Informational                      [Page 5]
+
+RFC 4024            Voice Messaging Client Behaviour           July 2005
+
+
+   In the case where several viewers are available for a single media
+   type, the user should be prompted to select the desired viewer on the
+   first occasion that the message type is encountered.  That viewer
+   should then become the default viewer for that media type.  The user
+   should have the ability to change the default viewer for a media type
+   at any time.
+
+   Note that it is possible that the media viewer may not be part of the
+   client or local to the host of the client.  For example, a user could
+   select to play a voice message from a GUI and the message is played
+   over a telephone (perhaps because the user has no desktop speakers).
+   Additionally, a user listening to a unified messaging inbox over a
+   TUI could chose to print a particular message to a nearby fax
+   machine.
+
+6.1.  Proposed Mechanism
+
+   As mentioned, the default viewer displayed to the user should be the
+   appropriate one for the primary message type.  The client is able to
+   determine the primary message type from the "Message-Context" message
+   header per [2].
+
+7.  Mark Message as Read
+
+   Obviously, the user must be able to know which messages they have
+   read, and which are unread.  This feature would also control the
+   message icon or earcon as mentioned in section 1.
+
+   With the proliferation of voice and fax messages, clients should only
+   indicate that these messages are read when the primary body part has
+   been read.  For example, a voice message should not be indicated as
+   read until the audio part has been played.  The default is currently
+   to mark a message read, when the first body part (typically text) is
+   viewed.
+
+7.1.  Proposed Mechanism
+
+   Implementation of this feature on most clients is a local issue.
+
+   For example, in the case of IMAP4 [6], these clients should only set
+   the \SEEN flag after the first attachment of the primary content type
+   has been opened.  That is, if the message context is voice message,
+   the \SEEN flag would be set after the primary voice message
+   (indicated by content-disposition [1] or content-criticality [8]) is
+   opened.
+
+
+
+
+
+
+Parsons & Maruszak           Informational                      [Page 6]
+
+RFC 4024            Voice Messaging Client Behaviour           July 2005
+
+
+8.  Security Considerations
+
+   The desirable client behaviours described here are intended to
+   provide the user with a better client experience.  However,
+   supporting the proposed behaviours described in this document does
+   not make a client immune from the risks of being a mail client.  That
+   is, the client is not responsible for the format of the message
+   received, it only interprets.  As a result, messages could be spoofed
+   or masqueraded to look like a message they are not to elicit a
+   desired client behaviour.  This could be used to fool the end user,
+   for example, into thinking a message was a voice message (because of
+   the icon) when it was not.
+
+9.  Informative References
+
+   [1]  Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail -
+        version 2 (VPIMv2)", RFC 3801, June 2004.
+
+   [2]  Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
+        Context for Internet Mail", RFC 3458, January 2003.
+
+   [3]  Parsons, G. and J. Maruszak, "Calling Line Identification for
+        Voice Mail Messages", RFC 3939, December 2004.
+
+   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [5]  Vaudreuil, G. and G. Parsons, "Content Duration MIME Header
+        Definition", RFC 3803, June 2004.
+
+   [6]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
+        RFC 3501, March 2003.
+
+   [7]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+        Extensions (MIME) Part One: Format of Internet Message Bodies",
+        RFC 2045, November 1996.
+
+   [8]  Burger, E., "Critical Content Multi-purpose Internet Mail
+        Extensions (MIME) Parameter", RFC 3459, January 2003.
+
+   [9]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.
+
+   [10] Parsons, G., "IMAP Voice Extensions", Work in Progress, June
+        1999.
+
+
+
+
+
+
+
+Parsons & Maruszak           Informational                      [Page 7]
+
+RFC 4024            Voice Messaging Client Behaviour           July 2005
+
+
+10.  Acknowledgments
+
+   This work was inspired by the discussion of "Proposed Mechanisms" for
+   IMAP that were detailed in a since expired work in progress entitled
+   "IMAP Voice Extensions" [10].  The authors would like to acknowledge
+   all those who contributed to that document.  In addition, Cheryl
+   Kinden, Derrick Dunne, and Jason Collins assisted in the editing of
+   previous revisions of this document.
+
+Author's Addresses
+
+   Glenn Parsons
+   Nortel Networks
+   P.O. Box 3511, Station C
+   Ottawa, ON  K1Y 4H7
+   Canada
+   Phone: +1-613-763-7582
+   Fax: +1-613-967-5060
+   EMail: gparsons@nortel.com
+
+   Janusz Maruszak
+   Phone: +1-416-885-0221
+   EMail: jjmaruszak@sympatico.ca
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parsons & Maruszak           Informational                      [Page 8]
+
+RFC 4024            Voice Messaging Client Behaviour           July 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Parsons & Maruszak           Informational                      [Page 9]
+