idnits 2.17.1 draft-ohta-ccc-video-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 181: '...TAT" and "HELP". The commands MUST be...' RFC 2119 keyword, line 338: '...dress may be and SHOULD be represented...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (March 1998) is 9532 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) == Missing Reference: 'RSVP' is mentioned on line 362, but not defined ** Obsolete normative reference: RFC 1890 (Obsoleted by RFC 3551) Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT M. Ohta 3 draft-ohta-ccc-video-01.txt Tokyo Institute of Technology 4 T. Tsushima 5 T. Tsushima 6 Victor Company of Japan, Limited (JVC) 7 H. FUJIWARA 8 Graphics Communication Laboratories 9 March 1998 11 Camera Recorder Control Protocol 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 To view the entire list of current Internet-Drafts, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 28 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 29 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 31 This document is also a product of HSI (Home System Interface) WG of 32 the multimedia standardization promotion commitee of Japanese 33 national committee of IEC. 35 Abstract 37 CRCP (Camera Recorder Control Protocol) is designed after FTP to be 38 useful to operate realtime/batch analog/digital video cameras and 39 video/audio recorders over the Internet. 41 The design of CRCP is completely modular. A unit consists of several 42 subunits and CRCP currently specifies units POWER, STREAM, TAPE and 43 CAMERA. However, CRCP allows arbitrary combination of subunits to 44 make it useful to control any home electronics units. 46 1. Introduction 48 CRCP (Camera Recorder Control Protocol) is a protocol to control 49 audio visual units to send or receive multimedia information over the 50 Internet. 52 The model of CRCP is that there are a controller (a client) and a 53 unit (a server). The controller issues commands and the unit receives 54 them. Responses are generated by the unit to be reported to the 55 controller. A unit may send or receive data stream to or from other 56 units. The controller does not generate data streams, though a 57 controller and a unit may be collocated in a host. A unit consists of 58 several subunits controlled independently. The unit-subunit model is 59 consistent with a model of IEEE.1394 TA and allows modular control of 60 various home electronics equipments. 62 The primary functions of CRCP are data transfer control, camera 63 control and tape control. Data transfer control is designed after the 64 existing data transfer protocol: FTP [FTP]. 66 The controlled unit may be just a plain file server for non-realtime 67 transfer, a VoD server with a realtime file system, a video camera 68 connected to realtime MPEG encoder, a virtual camera in VRML space or 69 an analog audio tape recorder connected to a PC sound board. 71 Filenames of CRCP may mean UNIX filenames, names of tapes in 72 automatic archive, names of input connectors, or names of TV 73 channels. Even if the unit does not support the notion of file, some 74 dummy filename should be supported. 76 CRCP uses a ASCII text command over TCP control channel. Thus, 77 long-haul control is possible without worrying about fair-share and 78 congestion avoidance algorithms. The default well known TCP port 79 number of the channel is . 81 If the controller, such as infra-red remote controller, has a 82 unidirectional interface, CRCP may also be used over UDP. No reply 83 will be given for UDP control and users are expected to confirm the 84 effect of the control by themselves, which is what we are doing with 85 infra-red remote controllers today. The default well known UDP port 86 number of the channel is . 88 If a host have multiple entities to be controlled by CRCP, different 89 port numbers should be used for the control channels. 91 Control commands and responses are exchanged over the control channel 92 with TELNET style ASCII. 94 Unlike FTP, it is required that server and client must support 95 monitor the control and data connections simultaneously. 97 CRCP assumes a single controller for each unit. The appropriate 98 interaction mechanisms between multiple controllers vary application 99 by application and should be handled application level coordination 100 entity, from which CRCP should be used to the unit. This assumption 101 does not prohibit multiple controllers control a multiport VoD server 102 independently port by port. 104 Like FTP, a controller may not be collocated on a sender nor a 105 receiver. A single controller may, of course, control several 106 senders and receivers to transmit data between them. 108 CRCP is designed to define a common and simple control interface of 109 camera recorders. CRCP capable controllers or units are not required 110 to support HTTP, HTML nor JAVA. CRCP commands may be issued by a 111 JAVA applet running in an HTML client. 113 2. Command Syntax 115 Commands of CRCP are ASCII string based and have the following syntax 116 with BNF-like notation (RFC2234 should be followed, here): 118 = ("STAT" / "HELP") [ ] CR LF / 119 [ ] [ ] 120 CR LF 122 = [] 124 = "POWER" / "CONNECTION" / "FILE" / "STREAM" / 125 "TAPE" / "CAMERA" / ... 127 = / 129 = 131 = / 133 = " " / TAB / " " / TAB 135 = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / 136 "9" 138 = / 140 = 142 If field is omitted in , the default is "0". 145 is different by . If 146 is ommitted in a command line, is 147 considered to be that of FTP [FTP] or its equivalent as described in 148 sections 6.2, 6.3 and 6.4. 150 The detailed syntax of the are different by . 153 3. Response Syntax 155 The response of CRCP has the same syntax and semantics as FTP [FTP]. 157 Responces are listed in Appendix A. 159 4. Command and Response Transport 161 Commands and responses of CRCP are usually carried over a TCP 162 connection as ASCII string with a default port number of . 165 If a controller can not receive IP packets or do not want to receive 166 CRCP response, CRCP commands may also be carried over UDP as ASCII 167 string with a default port number of . 168 Response is NOT returned over UDP. In this case, it is a 169 responsibility of a human user or intelligent application to judge 170 the effect of each command. Note that the UDP packets carrying CRCP 171 commands may not be able to reach the unit, or they may reach the 172 unit in an order different from that at the controller. Multiple 173 command lines may be included in a single UDP packets and executed 174 sequentially, unless error condition is encountered. The error may be 175 ignored and command line processing may continue or the error may 176 terminate the processing of the rest of the command lines in the 177 packet. 179 5. Basic Command 181 The basic command of CRCP is "STAT" and "HELP". The commands MUST be 182 supported by any unit. 184 5.1 STAT command 186 With no arguments, the command returns a list of available subunits 187 and subunit numbers of the unit. 189 With CRCP, four subunits, "POWER", "STREAM", "TAPE" and "CAMERA" with 190 subunit numbers of 0 are defined. The response to "STAT" command will 191 be: 193 211-status response 194 POWER0 195 CONNECTION0 196 FILE0 197 STREAM0 198 TAPE0 199 CAMERA0 200 211 status response 202 The order of subunits in the response is insignificant. 204 The "STAT" command may also be used with an argument of a subunit 205 name and a subunit number. 207 That is, "STATUS CAMERA" and "STATUS TAPE" are the valid form of the 208 STATUS command. There meanings are explained later with the related 209 subunits. 211 5.2 HELP command 213 HELP command always successes and returns responses useful to human 214 controlling the unit. With an optional subunit argument, HELP 215 response will be on the subunit. Detailed content of the response is 216 outside the scope of protocol issues. The response may be identical 217 to that of STAT. 219 6. Subunit Commands 221 Subunit commands are different subunit by subunit. 223 6.1 POWER subunit commands 225 POWER subunit has two subunit commands "ON" and "OFF" corresponding 226 to the functions of unit power on and off. 228 A unit may be able to receive some command even if the unit is 229 powered off. 231 6.2 CONNECTION subunit commands 233 The following subunit commands of CRCP are for connection management 234 and have exactly the same semantics as FTP. 236 USER NAME 238 PASSWORD 240 ACCOUNT 241 LOGOUT 243 No further explanation on them is given in this memo. 245 6.3 FILE subunit commands 247 The following subunit commands of CRCP are for file system management 248 and have exactly the same semantics as FTP. 250 CHANGE WORKING DIRECTORY 252 CHANGE TO PARENT DIRECTORY 254 STRUCTURE MOUNT 256 REINITIALIZE 258 PRINT WORKING DIRECTORY 260 LIST 262 NAMELIST 264 SYSTEM 266 No further explanation on them is given in this memo. 268 6.4 STREAM subunit commands 270 The following subcommands of STREAM subunit are extension of the 271 corresponding commands of FTP. The detail is explained in section 7. 273 DATA PORT (PORT) 275 PASSIVE (PASV) 277 REPRESENTATION TYPE (TYPE) 279 TRANSFER MODE (MODE) 281 RETRIEVE (RETR) 283 STORE (STOR) 285 ABORT (ABOR) 287 6.5 TAPE subunit commands 288 The following commands of CRCP are unique to CCCP to be used for TAPE 289 subunit control explained in section 8. 291 PLAY (PLAY) 293 PAUSE (PAUS) 295 RECORD (RECO) 297 FAST FORWARD (FF) 299 STATUS TAPE (STAT TAPE) 301 6.6 CAMERA subunit commands 303 The following commands of CRCP are unique to CCCP to be used for 304 CAMERA subunit control explained in section 9. 306 IRIS (IRIS) 308 SENSITIVITY (SENS) 310 ROLL (ROLL) 312 PAN (PAN) 314 TILT (TILT) 316 ZOOM (ZOOM) 318 HORIZONTAL (HORI) 320 VERTICAL (VERT) 322 DEPTH (DEPT) 324 FOCUS (FOCU) 326 WHITE BALANCE (WHIT) 328 STATUS CAMERA (STAT CAMERA) 330 FTP commands not mentioned in this section do not exist in CRCP. 332 7. Modified FTP Commands 334 DATA PORT (PORT) 335 PASSIVE (PASV) 337 Unlike FTP, a port number may be one for UDP depending on TRANSFER 338 MODE. A host address may be and SHOULD be represented by a DNS 339 domain name. The address may be a multicast address. 341 REPRESENTATION TYPE (TYPE) 343 The types supported by CRCP are A for ASCII, and I for RTP- 344 encapsulated audio/visual data. An ASCII type may be used only 345 for LIST and NAMELIST commands, and the second format parameter, 346 if any, should be N. The detailed format of Audio/visual data is 347 determined by the second parameter, which is a comma separated 348 list of decimal integers of well known RTP payload types [RFC1890] 349 to be sent or received. 351 TRANSFER MODE (MODE) 353 The modes supported by CRCP are S for Stream (TCP), P for Packet 354 (UDP). Packet mode uses UDP. Packet mode has a space separated 355 second unsigned decimal numeric parameter to indicated the number 356 of MPEG2-TS or RTP payloads included in a single UDP packet. Only 357 a single RTP payload may be included in a UDP packet. In a TCP 358 stream, RTP packets must be preceded by 2 byte bigendian headers 359 containing the length of the next RTP payload. The optional 360 second (for Stream mode) or third (for Packet mode) argument is an 361 ASCII string specifying QoS requirement to be used with RSVP 362 [RSVP]. The format of the string is, . If no 363 QoS is specified, transfer mode is best effort. 365 RETRIEVE (RETR) 367 These command initiate the transfer of data. When QoS is 368 specified with mode, PATH messages are also sent along with the 369 data. Note that, with tape unit, blank image, noise or just 370 silence may be sent unless PLAY command is issued. 372 STORE (STOR) 374 This command initiate the acceptance of data. When QoS is 375 specified with mode, RESV messages are also sent upstream. 377 ABORT (ABOR) 379 This command terminates the acceptance of data. Unlike FTP, no 380 special action is required, because CRCP servers must be able to 381 monitor multiple ports simultaneously. When QoS is specified with 382 mode, PATH or RESV messages are also stopped. 384 8. Tape Control Commands 386 Tape units, such as audio or video tape recorder or just a file, have 387 a notion of current tape position. 389 Some tape control commands have an argument to specify a tape 390 position. The position is represented in seconds with decimal 391 notation with optional fractional part. The integral part should be 392 between 2147483647 and -2147483648, that is, can be represented by a 393 32 bit signed integer. When '+' or '-' sign precedes the number, it 394 means a position relative to the current tape position. 396 Arguments are separated by a single space character. The precision 397 and range of the arguments are unit dependent and, sometimes, totally 398 ineffective. 400 PLAY (PLAY) 402 RECORD (REC) 404 Start playing or recording from the current tape position. 406 The optional second signed integer argument represented in decimal 407 notation with optional fractional part may designate the play or 408 record speed (e.g. 1 for normal play speed, -1 for reverse play or 409 record with the normal speed). 411 The optional third argument may designate the position to stop 412 playing or recording. If the stop position is already behind the 413 current tape position (depending on the direction of the movement) 414 at the beginning of the command, the command terminates. 416 PAUSE (PAUS) 418 Stop playing, recording or fast forwarding at the current 419 position. 421 FAST FORWARD (FF) 423 An optional second signed integer argument represented in decimal 424 notation with optional fractional part may designate the 425 forwarding speed (e.g. 5 for fast forward, -5 for rewind). 427 Move the current tape position forward (or backward). An optional 428 third argument may designate the position to stop operation. If 429 the stop position is already behind the current tape position 430 (depending on the direction of the movement) at the beginning of 431 the command, the command terminates. 433 During the operation, image or sound may or may not be sent out 434 depending on the nature of the unit. 436 STATUS TAPE (STAT TAPE) 438 Will cause multiline response. The first line begins with the 439 name of the command in operation (PAUS if nothing) followed by a 440 decimal integer with optional fractional part to show the current 441 tape position. Other lines begins with the tape control command 442 name supported by the unit. If the command has numeric arguments, 443 two numbers separated by a comma will be returned which designate 444 the minimum and the maximum meaningful value of the corresponding 445 command parameter. 447 Reply code of tape control commands will be "200 Command okay", "501 448 Syntax error" in parameters or arguments" or "502 Command not 449 implemented". 451 9. Camera Control Commands 453 Viewing parameters of camera units are controlled by camera control 454 commands. 456 Camera control commands other than CAMERA STATUS have a single 457 argument to specify the view. 459 The argument is usually numeric and is represented with decimal 460 notation with optional fractional part. The integral part should be 461 between 2147483647 and -2147483648, that is, can be represented by a 462 32 bit signed integer. When '+' or '-' sign precedes the number, it 463 means a value relative to the current value. 465 The argument may be a single character '+' or '-' with no decimal 466 characters, in which case, the view changes some meaningful small 467 amount toward the direction of the sign. 469 The precision and range of the argument is unit dependent and, 470 sometimes, be totally ineffective. 472 The argument may also be a special keyword "AUTO", in which case, the 473 viewing parameter is controlled in a unit dependent manner. The 474 intention is to set the parameter automatically to make the view 475 comfortable. 477 IRIS (IRIS) 479 Controls iris of a camera. Positive direction makes iris more 480 open. 482 SENSITIVITY (SENS) 484 Controls sensitivity of a (CCD) camera. Positive direction makes 485 image brighter. 487 ROLL (ROLL) 489 Controls roll angle of a camera. Positive direction turns the 490 camera clockwise viewed behind the camera. 492 PAN (PAN) 494 Controls pan angle of a camera. Positive direction makes view move 495 right. 497 TILT (TILT) 499 Controls tilt angle of a camera. Positive direction makes view 500 move up. 502 ZOOM (ZOOM) 504 Controls viewing angle of a camera. Positive direction makes view 505 angle narrower (more zoom). 507 HORIZONTAL (HORI) 509 Moves a camera horizontally. Positive HORIZONTAL movement moves 510 the camera right viewed behind the camera. 512 VERTICAL (VERT) 514 Moves a camera vertically. Positive VERTICAL movement moves the 515 camera to the upward direction.. 517 DEPTH (DEPT) 519 Moves a camera along the viewing direction. Positive DEPTH 520 movement moves the camera forward. 522 FOCUS (FOCU) 524 Controls focal point of a camera. Positive direction makes the 525 focal point farther. 527 WHITE BALANCE (WHIT) 529 Controls white balance of a camera represented as a color 530 temperature, unit of which is Kelvin. Positive direction makes 531 color temperature higher. 533 STATUS CAMERA (STAT CAMERA) 535 Will cause multiline response. The first line contain some string 536 such as "OK", which is ignored. Other lines begin with the camera 537 control command name supported by the unit followed by three 538 numbers separated by a comma which designates the minimum 539 meaningful, the current and maximum meaningful values of the 540 corresponding viewing parameter. For the non-commutative commands 541 of camera motion control, the order of them in the reply is 542 significant. They are ordered according to the order of 543 application of motions to the camera. For example, if rotations 544 are applied first to the camera and then translation is applied, 545 rotation commands appear before translation commands in the reply 546 of the STATUS CAMERA command, 548 Reply code of camera control commands will be "200 Command okay", 549 "501 Syntax error in parameters or arguments" or "502 Command not 550 implemented". 552 10. URL 554 The URL for CRCP is identical to that of FTP, except that it start 555 with "cccp" and have a different default port number . The URL is shared both by TCP and UDP control. 558 11. References 560 [FTP] STD9, RFC959. 562 [RFC1890] RFC1890. 564 12. Appendix A. List of Responces 566 13. Security Considerations 568 CRCP is designed after FTP and, with TCP control, is just as secure 569 as FTP. 571 That is, CRCP control connection to servers can be protected by 572 password. 574 As the password-based security is not so secure, it is encouraged to 575 deploy IPSEC security mechanisms, when they become stable enough. An 576 easy, almost configurationless, key exchange mechanism suitable for 577 home electronics use should be developed. 579 It is also possible to let the reply to USER command contain seeds 580 for one time password, but nothing is specified in this memo, partly 581 because it is a waste of effort to develop CRCP's own security 582 mechanism and partly because it is not useful with one way control 583 through UDP. 585 For UDP-based one way control, synchronized clocks should be used to 586 close the window of the replay attacks. 588 14. Authors' Addresses 590 Masataka Ohta 591 Computer Center 592 Tokyo Institute of Technology 593 2-12-1, O-okayama, Meguro-ku 594 Tokyo 152-8550, JAPAN 596 Phone: +81-3-5734-3299 597 Fax: +81-3-5734-3415 598 EMail: mohta@necom830.hpcl.titech.ac.jp 600 Takuya Tsushima 601 Video System Development Laboratories 602 Victor Company of Japan, Limited 603 12, 3-chome, Moriya-cho, Kanagawa-ku, Yokohama, 604 Kanagawa 221, Japan 606 Phone : +81 45 450 2458 607 Fax : +81 45 450 2469 608 EMail : tsushima@krhm.jvc-victor.co.jp 610 Hiroshi FUJIWARA 611 Graphics Communication Laboratories 612 6F Annex Tohshin Bldg, 613 4-36-19, Yoyogi, Shibuya-ku 614 TOKYO 151, JAPAN 616 Phone: +81 3 5351 0181 617 Fax: +81 3 5351 0184 618 EMail: fujiwara@gctech.co.jp