idnits 2.17.1 draft-ietf-avt-pointer-00.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 is 1 instance of too long lines in the document, the longest one being 6 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 152 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 (October 4, 1999) is 8969 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 October 4, 1999 3 File: draft-ietf-avt-pointer-00.txt Expires: April, 4 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 1. Introduction 37 In most presentations, significant information is conveyed through the 38 use of viewgraphs and a pointer. This makes accurate transmission of 39 them vital in remote conferencing applications. Using regular video of 40 a presenter's display for this purpose is problematic because, while 41 the viewgraphs require a high spatial resolution, the pointer 42 movements need to be sampled and transmitted at a high temporal 43 resolution so that the presenter's pointing actions can be displayed 44 synchronously with the corresponding audio and video signals. In many 45 instances, this synchronization carries vital information. As an 46 example, consider a speaker pointing at two alternatives on a 47 viewgraph in sequence and saying "this one is better than this." To 48 satisfy both high spatial and high temporal resolution requirements, 49 at least S-VHS quality video may need to be used. Codecs that can 50 compress S-VHS video effectively in real-time are expensive for this 51 purpose, and transmitting such video uncompressed requires very high 52 bandwidths. 54 A much simpler and economical system can be designed by capturing and 55 transmitting the pointer coordinates separately [2]. The pointer 56 coordinates with respect to a displayed viewgraph can easily be 57 obtained in electronic presentation systems. For presentations 58 prepared for optical systems, such as transparencies for overhead 59 projectors, an arrangement where the viewgraph is captured in a frame 60 buffer on a computer can be used to associate the pointer coordinates 61 with the displayed viewgraph. For capturing transparencies, printed 62 material, or even three dimensional objects, a document camera and a 63 personal computer or workstation based video capture card can be used. 64 This arrangement can handle electronic viewgraphs by feeding the video 65 output of the computer that displays them to the video capture card 66 through an appropriate converter also. A side benefit of this is that 67 it allows using a presenter's own computer to transmit electronic 68 viewgraphs without connecting it to, for example, an intranet. The 69 captured image is then displayed along with the capturing computer's 70 mouse pointer on the presenter's display using a projector. The 71 presenter moves the pointer on the display using a regular or maybe a 72 wireless mouse whose location can easily be captured by appropriate 73 software running on the capturing computer. 75 This document describes an RTP payload format to transmit the pointer 76 coordinates captured in one of the ways described above using RTP. 77 Although, a mouse can be used as the pointer, this payload format is 78 not intended and may not have all functionalities needed to implement 79 a general mouse event transmission mechanism. 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [3]. 85 2. Payload Format 87 0 1 2 3 88 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 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 |V=2|P|X| CC |M| PT | sequence number | 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 | timestamp | 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | synchronization source (SSRC) identifier | 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 : contributing source (CSRC) identifiers : 97 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 98 |L|M|R| | x-coordinate | | PIN | y-coordinate | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 MBZ MBZ 101 Figure 1 - An RTP packet for Real-Time Pointer 103 Fig. 1 shows an RTP packet carrying real-time pointer coordinates. 104 This payload format does not have a payload specific header. 106 2.1. RTP Header Usage: 108 Payload Type (PT): The assignment of an RTP payload type for this new 109 packet format is outside the scope of this document, and will not be 110 specified here. It is expected that the RTP profile for a particular 111 class of applications will assign a payload type for this encoding, or 112 if that is not done then a payload type in the dynamic range shall be 113 chosen. 115 Marker (M) bit: Set to one if the pointer icon is changed in this 116 packet. 118 Extension (X) bit: Defined by the RTP profile used. 120 Sequence Number: Set as described in RFC1889 [1]. 122 Timestamp: The sampling time for the pointer location measured by a 123 90kHz clock. 125 SSRC: Set as described in RFC1889 [1]. 127 CC and CSRC fields are used as described in RFC 1889 [1]. 129 RTCP SHOULD be used as defined in RFC 1889 [1]. 131 2.2. Payload: 133 The pointer's x and y coordinates are measured from the upper left 134 corner of the associated display window. They are represented as a 135 fraction of the corresponding edge length of the display using 12 136 bits, positive, fixed point numbers between 0 and (1 - 2^-12). 138 L (left), R (right) and/or M (middle) bits are set to one if their 139 respective "mouse" buttons are down at the sampling time. 141 PIN: Pointer Icon Number (3 bits) selects a pointer icon. The 142 association between the PIN numbers and the icon pictures MUST be 143 established out-of-band. PIN = 0 represents a default pointer icon. 145 3. Security Considerations 147 RTP packets using the payload format defined in this specification are 148 subject to the security considerations discussed in the RTP 149 specification [1]. 151 This payload type does not exhibit any significant non-uniformity in 152 the receiver side computational complexity for packet processing to 153 cause a potential denial-of-service threat. 155 4. References 157 [1] Schulzrinne, Casner, Frederick, Jacobson RTP: A 158 Transport Protocol for Real Time Applications RFC 1889, 159 Internet Engineering Task Force, January 1996. 161 [2] M. R. Civanlar, G. L. Cash, "Networked Viewgraphs - NetVG" Proceedings 162 of The 9th Int. Workshop on Packet Video, 163 http://www.reseach.att.com/~mrc/PacketVideo99.html. 165 [3] S. Bradner, Key words for use in RFCs to Indicate 166 Requirement Levels, RFC 2119, March 1997. 168 7. Authors' Addresses 170 M. Reha Civanlar 171 AT&T Labs - Research 172 100 Schultz Drive 173 Room 3-205 174 Red Bank, NJ 07701 175 USA 176 e-mail: civanlar@research.att.com 178 Glenn L. Cash 179 AT&T Labs - Research 180 100 Schultz Drive 181 Room 3-213 182 Red Bank, NJ 07701 183 USA 184 e-mail: glenn@research.att.com