idnits 2.17.1 draft-ietf-avt-pointer-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 198 has weird spacing: '...cessing to...' -- 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 (January 31, 2000) is 8851 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) ** Obsolete normative reference: RFC 1889 (ref. '1') (Obsoleted by RFC 3550) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Civanlar & Cash - AT&T 2 INTERNET DRAFT January 31, 2000 3 File: draft-ietf-avt-pointer-01.txt Expires: July 31, 2000 5 RTP Payload Format for Real-Time Pointers 7 STATUS OF THIS MEMO 9 This document is an Internet-Draft and is in full conformance with all 10 provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering Task 13 Force (IETF), its areas, and its working groups. Note that other 14 groups may also distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 This document describes an RTP [1] payload format for transporting the 30 coordinates of a dynamic pointer that may be used during a 31 presentation. Although a mouse can be used as the pointer, this 32 payload format is not intended and may not have all functionalities 33 needed to implement a general mouse event transmission mechanism. 35 This version of the draft includes MIME type registration information 36 and a wording change in Section 2.2 for clarification. 38 1. Introduction 40 In most presentations, significant information is conveyed through the 41 use of viewgraphs and a pointer. This makes accurate transmission of 42 them vital in remote conferencing applications. Using regular video of 43 a presenter's display for this purpose is problematic because, while 44 the viewgraphs require a high spatial resolution, the pointer 45 movements need to be sampled and transmitted at a high temporal 46 resolution so that the presenter's pointing actions can be displayed 47 synchronously with the corresponding audio and video signals. In many 48 instances, this synchronization carries vital information. As an 49 example, consider a speaker pointing at two alternatives on a 50 viewgraph in sequence and saying "this one is better than this." To 51 satisfy both high spatial and high temporal resolution requirements, 52 at least S-VHS quality video may need to be used. Codecs that can 53 compress S-VHS video effectively in real-time are expensive for this 54 purpose, and transmitting such video uncompressed requires very high 55 bandwidths. 57 A much simpler and economical system can be designed by capturing and 58 transmitting the pointer coordinates separately [2]. The pointer 59 coordinates with respect to a displayed viewgraph can easily be 60 obtained in electronic presentation systems. For presentations 61 prepared for optical systems, such as transparencies for overhead 62 projectors, an arrangement where the viewgraph is captured in a frame 63 buffer on a computer can be used to associate the pointer coordinates 64 with the displayed viewgraph. For capturing transparencies, printed 65 material, or even three dimensional objects, a document camera and a 66 personal computer or workstation based video capture card can be used. 67 This arrangement can handle electronic viewgraphs by feeding the video 68 output of the computer that displays them to the video capture card 69 through an appropriate converter also. A side benefit of this is that 70 it allows using a presenter's own computer to transmit electronic 71 viewgraphs without connecting it to, for example, an intranet. The 72 captured image is then displayed along with the capturing computer's 73 mouse pointer on the presenter's display using a projector. The 74 presenter moves the pointer on the display using a regular or maybe a 75 wireless mouse whose location can easily be captured by appropriate 76 software running on the capturing computer. 78 This document describes an RTP payload format to transmit the pointer 79 coordinates captured in one of the ways described above using RTP. 80 Although, a mouse can be used as the pointer, this payload format is 81 not intended and may not have all functionalities needed to implement 82 a general mouse event transmission mechanism. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [3]. 88 2. Payload Format 90 0 1 2 3 91 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 |V=2|P|X| CC |M| PT | sequence number | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | timestamp | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | synchronization source (SSRC) identifier | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 : contributing source (CSRC) identifiers : 100 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 101 |L|M|R| | x-coordinate | | PIN | y-coordinate | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 MBZ MBZ 104 Figure 1 - An RTP packet for Real-Time Pointer 106 Fig. 1 shows an RTP packet carrying real-time pointer coordinates. 107 This payload format does not have a payload specific header. 109 2.1. RTP Header Usage: 111 Payload Type (PT): The assignment of an RTP payload type for this new 112 packet format is outside the scope of this document, and will not be 113 specified here. It is expected that the RTP profile for a particular 114 class of applications will assign a payload type for this encoding, or 115 if that is not done then a payload type in the dynamic range shall be 116 chosen. 118 Marker (M) bit: Set to one if the pointer icon is changed in this 119 packet. 121 Extension (X) bit: Defined by the RTP profile used. 123 Sequence Number: Set as described in RFC1889 [1]. 125 Timestamp: The sampling time for the pointer location measured by a 126 90kHz clock. 128 SSRC: Set as described in RFC1889 [1]. 130 CC and CSRC fields are used as described in RFC 1889 [1]. 132 RTCP SHOULD be used as defined in RFC 1889 [1]. 134 2.2. Payload: 136 The pointer's x and y coordinates are measured from the upper left 137 corner of the associated display window. They are represented as a 138 fraction of the corresponding edge length of the display window using 139 12 bits, positive, fixed point numbers between 0 and (1 - 2^-12). 141 L (left), R (right) and/or M (middle) bits are set to one if their 142 respective "mouse" buttons are down at the sampling time. 144 PIN: Pointer Icon Number (3 bits) selects a pointer icon. The 145 association between the PIN numbers and the icon pictures MUST be 146 established out-of-band. PIN = 0 represents a default pointer icon. 148 3. MIME Media Type Registrations 150 This document defines a new RTP payload name, "pointer," and 151 associated MIME subtype, "video/pointer." The registration form for 152 this MIME subtype has been submitted to IANA. 154 3.1. Registration of MIME media type video/pointer 156 MIME media type name: video 158 MIME subtype name: pointer 160 Required parameters: None 162 Optional parameters: None 164 Encoding considerations: Pointer video can be transmitted 165 with RTP as specified in "draft-ietf-avt-pointer-01". 167 Security considerations: As described in "draft-ietf-avt-pointer-01" 169 Interoperability considerations: None 171 Published specification: draft-ietf-avt-pointer-01 173 Applications which use this media type: 174 Videoconferencing systems that transmit VUgraphs with a real-time pointer. 176 Additional information: None 178 Magic number(s): None 179 File extension(s): None 180 Macintosh File Type Code(s): None 182 Person & email address to contact for further information: 183 M. Reha Civanlar 184 e-mail: civanlar@research.att.com 186 Intended usage: COMMON 187 Author/Change controller: 188 M. Reha Civanlar 189 e-mail: civanlar@research.att.com 191 4. Security Considerations 193 RTP packets using the payload format defined in this specification are 194 subject to the security considerations discussed in the RTP 195 specification [1]. 197 This payload type does not exhibit any significant non-uniformity in 198 the receiver side computational complexity for packet processing to 199 cause a potential denial-of-service threat. 201 4. References 203 [1] Schulzrinne, Casner, Frederick, Jacobson RTP: A 204 Transport Protocol for Real Time Applications RFC 1889, 205 Internet Engineering Task Force, January 1996. 207 [2] M. R. Civanlar, G. L. Cash, "Networked Viewgraphs - NetVG" Proceedings 208 of The 9th Int. Workshop on Packet Video, 209 http://www.reseach.att.com/~mrc/PacketVideo99.html. 211 [3] S. Bradner, Key words for use in RFCs to Indicate 212 Requirement Levels, RFC 2119, March 1997. 214 7. Authors' Addresses 216 M. Reha Civanlar 217 AT&T Labs - Research 218 100 Schultz Drive 219 Room 3-205 220 Red Bank, NJ 07701, USA 221 e-mail: civanlar@research.att.com 223 Glenn L. Cash 224 AT&T Labs - Research 225 100 Schultz Drive 226 Room 3-213 227 Red Bank, NJ 07701, USA 228 e-mail: glenn@research.att.com