doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc2862.txt b/doc/rfc/rfc2862.txt
new file mode 100644
index 0000000..22d4092
--- /dev/null
+++ b/doc/rfc/rfc2862.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                        M. Civanlar
+Request for Comments: 2862                                       G. Cash
+Category: Standards Track                                           AT&T
+                                                               June 2000
+
+
+               RTP Payload Format for Real-Time Pointers
+
+Status 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 (2000).  All Rights Reserved.
+
+Abstract
+
+   This document describes an RTP [1] payload format for transporting
+   the coordinates of a dynamic pointer that may be used during a
+   presentation. Although a mouse can be used as the pointer, this
+   payload format is not intended and may not have all functionalities
+   needed to implement a general mouse event transmission mechanism.
+
+1. Introduction
+
+   In most presentations, significant information is conveyed through
+   the use of viewgraphs and a pointer. This makes accurate transmission
+   of them vital in remote conferencing applications. Using regular
+   video of a presenter's display for this purpose is problematic
+   because, while the viewgraphs require a high spatial resolution, the
+   pointer movements need to be sampled and transmitted at a high
+   temporal resolution so that the presenter's pointing actions can be
+   displayed synchronously with the corresponding audio and video
+   signals. In many instances, this synchronization carries vital
+   information.  As an example, consider a speaker pointing at two
+   alternatives on a viewgraph in sequence and saying "this one is
+   better than this".  To satisfy both high spatial and high temporal
+   resolution requirements, at least S-VHS quality video may need to be
+   used. Codecs that can compress S-VHS video effectively in real-time
+   are expensive for this purpose, and transmitting such video
+   uncompressed requires very high bandwidths.
+
+
+
+
+
+Civanlar & Cash             Standards Track                     [Page 1]
+
+RFC 2862       RTP Payload Format for Real-Time Pointers       June 2000
+
+
+   A much simpler and economical system can be designed by capturing and
+   transmitting the pointer coordinates separately [2]. The pointer
+   coordinates with respect to a displayed viewgraph can easily be
+   obtained in electronic presentation systems. For presentations
+   prepared for optical systems, such as transparencies for overhead
+   projectors, an arrangement where the viewgraph is captured in a frame
+   buffer on a computer can be used to associate the pointer coordinates
+   with the displayed viewgraph. For capturing transparencies, printed
+   material, or even three dimensional objects, a document camera and a
+   personal computer or workstation based video capture card can be
+   used.  This arrangement can handle electronic viewgraphs by feeding
+   the video output of the computer that displays them to the video
+   capture card through an appropriate converter also. A side benefit of
+   this is that it allows using a presenter's own computer to transmit
+   electronic viewgraphs without connecting it to, for example, an
+   intranet. The captured image is then displayed along with the
+   capturing computer's mouse pointer on the presenter's display using a
+   projector. The presenter moves the pointer on the display using a
+   regular or maybe a wireless mouse whose location can easily be
+   captured by appropriate software running on the capturing computer.
+
+   This document describes an RTP payload format to transmit the pointer
+   coordinates captured in one of the ways described above using RTP.
+   Although, a mouse can be used as the pointer, this payload format is
+   not intended and may not have all functionalities needed to implement
+   a  general mouse event transmission mechanism.
+
+   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 [3].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Civanlar & Cash             Standards Track                     [Page 2]
+
+RFC 2862       RTP Payload Format for Real-Time Pointers       June 2000
+
+
+2. Payload Format
+
+    0                   1                   2                   3
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           timestamp                           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           synchronization source (SSRC) identifier            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   :            contributing source (CSRC) identifiers             :
+   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+   |L|M|R| |     x-coordinate      | | PIN |     y-coordinate      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+         MBZ                       MBZ
+
+               Figure 1 - An RTP packet for Real-Time Pointer
+
+   Fig. 1 shows an RTP packet carrying real-time pointer coordinates.
+   This payload format does not have a payload specific header.
+
+2.1. RTP Header Usage:
+
+   Payload Type (PT): The assignment of an RTP payload type for this new
+   packet format is outside the scope of this document, and will not be
+   specified here. It is expected that the RTP profile for a particular
+   class of applications will assign a payload type for this encoding,
+   or if that is not done then a payload type in the dynamic range shall
+   be chosen.
+
+   Marker (M) bit: Set to one if the pointer icon is changed in this
+   packet.
+
+   Extension (X) bit: Defined by the RTP profile used.
+
+   Sequence Number: Set as described in RFC1889 [1].
+
+   Timestamp: The sampling time for the pointer location measured by a
+   90kHz clock.
+
+   SSRC: Set as described in RFC1889 [1].
+
+   CC and CSRC fields are used as described in RFC 1889 [1].
+
+   RTCP SHOULD be used as defined in RFC 1889 [1].
+
+
+
+
+
+Civanlar & Cash             Standards Track                     [Page 3]
+
+RFC 2862       RTP Payload Format for Real-Time Pointers       June 2000
+
+
+2.2. Payload:
+
+   The pointer's x and y coordinates are measured from the upper left
+   corner of the associated display window. They are represented as a
+   fraction of the corresponding edge length of the display window using
+   12 bits, positive, fixed point numbers between 0 and (1 - 2^-12).
+
+   L (left), R (right) and/or M (middle) bits are pointer special
+   effects flags. Their use is application dependent and MUST be
+   established out-of-band. Applications MAY ignore these bits.
+
+   PIN: Pointer Icon Number (3 bits) selects a pointer icon.  The
+   association between the PIN numbers and the icon pictures MUST be
+   established out-of-band. PIN = 0 represents a default pointer icon.
+   Applications which only support a single pointer icon SHOULD set the
+   PIN field to zero. Applications MAY ignore non-zero PIN values on
+   reception, and display a default icon.
+
+3. MIME Media Type Registrations
+
+   This document defines a new RTP payload name, "pointer," and
+   associated MIME subtype, "video/pointer."
+
+3.1. Registration of MIME media type video/pointer
+
+      MIME media type name: video
+
+      MIME subtype name: pointer
+
+      Required parameters: None
+
+      Optional parameters: None
+
+      Encoding considerations: Pointer video can be transmitted with RTP
+      as specified in this document.
+
+      Security considerations: As described in this document.
+
+      Interoperability considerations: None
+
+      Published specification: this document.
+
+      Applications which use this media type: Videoconferencing systems
+      that transmit VUgraphs with a real-time pointer.
+
+      Additional information: None
+
+        Magic number(s): None
+
+
+
+Civanlar & Cash             Standards Track                     [Page 4]
+
+RFC 2862       RTP Payload Format for Real-Time Pointers       June 2000
+
+
+        File extension(s): None
+        Macintosh File Type Code(s): None
+
+      Person & email address to contact for further information:
+        M. Reha Civanlar
+        e-mail: civanlar@research.att.com
+
+      Intended usage: COMMON Author/Change controller:
+        M. Reha Civanlar
+        e-mail: civanlar@research.att.com
+
+4. Security Considerations
+
+   RTP packets using the payload format defined in this specification
+   are subject to the security considerations discussed in the RTP
+   specification [1].
+
+   This payload type does not exhibit any significant non-uniformity in
+   the receiver side computational complexity for packet processing  to
+   cause a potential denial-of-service threat.
+
+5. References
+
+   [1] Schulzrinne, H., Casner, S.,  Frederick, R. and V. Jacobson,
+       "RTP: A Transport Protocol for Real Time Applications", RFC 1889,
+       January 1996.
+
+   [2] M. R. Civanlar, G. L. Cash, "Networked Viewgraphs - NetVG"
+       Proceedings of The 9th Int. Workshop on Packet Video,
+       http://www.research.att.com/~mrc/PacketVideo99.html.
+
+   [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Civanlar & Cash             Standards Track                     [Page 5]
+
+RFC 2862       RTP Payload Format for Real-Time Pointers       June 2000
+
+
+6. Authors' Addresses
+
+   M. Reha Civanlar
+   AT&T Labs - Research
+   100 Schultz Drive, Room 3-205
+   Red Bank, NJ 07701, USA
+
+   EMail: civanlar@research.att.com
+
+
+   Glenn L. Cash
+   AT&T Labs - Research
+   100 Schultz Drive, Room 3-213
+   Red Bank, NJ 07701, USA
+
+   EMail: glenn@research.att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Civanlar & Cash             Standards Track                     [Page 6]
+
+RFC 2862       RTP Payload Format for Real-Time Pointers       June 2000
+
+
+7.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Civanlar & Cash             Standards Track                     [Page 7]
+