Movatterモバイル変換

Network Working Group                                          T. HansenRequest for Comments: 3938                             AT&T LaboratoriesUpdates:3458                                               October 2004Category: Standards TrackVideo-Message Message-ContextStatus of this Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2004).Abstract   The Message-Context header defined inRFC 3458 describes the context   of a message (for example: fax-message or voice-message).  This   specification extends the Message-Context header with one additional   context value: "video-message".   A receiving user agent (UA) may use this information as a hint to   optimally present the message.1.  Introduction   Email messages can be used to convey many different forms of   messages, and the user will interact with different types in   different ways.  As explained inRFC 3458 [1], the "message context"   of the message conveys information about the way the user expects to   interact with the message, such as which icon to display.RFC 3458   then registers the message contexts for a "voice-message", "fax-   message", "pager-message", "multimedia-message", "text-message", and   "none".Hansen                      Standards Track                     [Page 1]

RFC 3938             Video-Message Message-Context          October 20042.  Video Message   One form of email is a message that consists mostly of a video   stream.  Examples of services that send video email are those   connected to cell phones that capture video streams, and video email   services that use webcams attached to a PC.  These email messages   currently consist of two flavors, both of which can be properly   considered a video message:   1. those that embed the video stream internally within the message as      a body part, and   2. those whose video stream is stored on a third party's video      server.   However, none of the existing message contexts properly identify such   video messages.  This specification extends the Message-Context   header with one additional context value: video-message.3.  IANA Considerations3.1.  Message-Context   As specified inRFC 3458 [1], this document registers "video-message"   in the "Internet Message Context Types" repository.   Message-Context class name:      video-message   Summary of the message class:      Indicates a message whose primary content is a video mail message.      The primary content is video data.  The context is usually a      message recorded on a video camera, or a message whose primary      purpose is to contain an external reference to a message recorded      on a video camera.   Person & email address to contact for further information:      Tony Hansen, tony+msgctxt@maillennium.att.com.4.  Security Considerations   This header is intended to be an indicator of message context only.   As such, it is only a hint and requires no behavior on the part of a   message user agent.Hansen                      Standards Track                     [Page 2]

RFC 3938             Video-Message Message-Context          October 20045.  Normative References   [1]  Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message        Context for Internet Mail",RFC 3458, January 2003.6.  Author's Address   Tony Hansen   AT&T Laboratories   200 Laurel Ave.   Middletown, NJ  07748   USA   EMail: tony+msgctxt@maillennium.att.comHansen                      Standards Track                     [Page 3]

RFC 3938             Video-Message Message-Context          October 20047.  Full Copyright Statement   Copyright (C) The Internet Society (2004).   This document is subject to the rights, licenses and restrictions   contained inBCP 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 IETF's procedures with respect to rights in IETF Documents can   be found inBCP 78 andBCP 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 athttp://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.Hansen                      Standards Track                     [Page 4]