idnits 2.17.1 draft-hansen-lemonade-msgctxt-videomsg-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 159. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 136. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 143. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 149. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 165), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC3458, but the abstract doesn't seem to directly say this. It does mention RFC3458 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC3458, updated by this document, for RFC5378 checks: 2000-08-09) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 23, 2004) is 7247 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Hansen 3 Internet-Draft AT&T Laboratories 4 Updates: RFC 3458 (if approved) June 23, 2004 5 Expires: December 22, 2004 7 Video-Message Message-Context 8 draft-hansen-lemonade-msgctxt-videomsg-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 22, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 The Message-Context header defined in RFC 3458 [1] describes the 42 context of a message (for example: fax-message or voice-message). 43 This specification extends the Message-Context header with one 44 additional context value: "video-message". 46 A receiving user agent (UA) may use this information as a hint to 47 optimally present the message. 49 Note 50 This document is being discussed in the LEMONADE and VPIM working 51 group mailing lists, lemonade@ietf.org and vpim@ietf.org. 53 1. Introduction 55 Email messages can be used to convey many different forms of 56 messages, and the user will interact with different types in 57 different ways. As explained in RFC 3458 [1], the "message context" 58 of the message conveys information about the way the user expects to 59 interact with the message, such as which icon to display. RFC 3458 60 then registers the message contexts for a "voice-message", 61 "fax-message", "pager-message", "multimedia-message", "text-message" 62 and "none". 64 1.1 Changes from version 00 66 The description of RFC 3458 in the Introduction was shortened. 68 2. Video Message 70 One form of email is a message that consists mostly of a video 71 stream. Examples of services that send video email are those 72 connected to cell phones that capture video streams, and video email 73 services that use webcams attached to a PC. These email messages 74 currently consist of two flavors, both of which can be properly 75 considered to be a video message: 77 1. those that embed the video stream internally within the message 78 as a body part, and 80 2. those whose video stream is stored on a 3rd party's video server. 82 However, none of the existing message contexts properly identify such 83 video messages. This specification extends the Message-Context 84 header with one additional context value: video-message. 86 3. IANA Considerations 88 3.1 Message-Context 90 As specified in RFC 3458 [1], this document registers "video-message" 91 in the "Internet Message Context Types" repository. 93 Message-Context class name: 94 video-message 96 Sumary of the message class: 97 Indicates a message whose primary content is a video mail message. 98 The primary content is video data. The context is usually a 99 message recorded using a video camera, or a message whose primary 100 purpose is to contain an external reference to a message recorded 101 using a video camera. 103 Person & email address to contact for further information: 104 Tony Hansen, tony+msgctxt@maillennium.att.com. 106 4. Security Considerations 108 The intention for this header is to be an indicator of message 109 context only. As such, it is only a hint and requires no behavior on 110 the part of a message user agent. 112 5 Normative References 114 [1] Burger, E., Candell, E., Eliot, C. and G. Klyne, "Message 115 Context for Internet Mail", RFC 3458, January 2003. 117 Author's Address 119 Tony Hansen 120 AT&T Laboratories 121 200 Laurel Ave. 122 Middletown, NJ 07748 123 USA 125 EMail: tony+msgctxt@maillennium.att.com 127 Intellectual Property Statement 129 The IETF takes no position regarding the validity or scope of any 130 Intellectual Property Rights or other rights that might be claimed to 131 pertain to the implementation or use of the technology described in 132 this document or the extent to which any license under such rights 133 might or might not be available; nor does it represent that it has 134 made any independent effort to identify any such rights. Information 135 on the procedures with respect to rights in RFC documents can be 136 found in BCP 78 and BCP 79. 138 Copies of IPR disclosures made to the IETF Secretariat and any 139 assurances of licenses to be made available, or the result of an 140 attempt made to obtain a general license or permission for the use of 141 such proprietary rights by implementers or users of this 142 specification can be obtained from the IETF on-line IPR repository at 143 http://www.ietf.org/ipr. 145 The IETF invites any interested party to bring to its attention any 146 copyrights, patents or patent applications, or other proprietary 147 rights that may cover technology that may be required to implement 148 this standard. Please address the information to the IETF at 149 ietf-ipr@ietf.org. 151 Disclaimer of Validity 153 This document and the information contained herein are provided on an 154 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 155 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 156 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 157 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 158 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 159 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 161 Copyright Statement 163 Copyright (C) The Internet Society (2004). This document is subject 164 to the rights, licenses and restrictions contained in BCP 78, and 165 except as set forth therein, the authors retain all their rights. 167 Acknowledgment 169 Funding for the RFC Editor function is currently provided by the 170 Internet Society.