home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2431.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  22.3 KB  |  564 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           D. Tynan
  8. Request for Comments: 2431                                Claddagh Films
  9. Category: Standards Track                                   October 1998
  10.  
  11.  
  12.               RTP Payload Format for BT.656 Video Encoding
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. Copyright Notice
  23.  
  24.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  25.  
  26. Abstract
  27.  
  28.    This document specifies the RTP payload format for encapsulating ITU
  29.    Recommendation BT.656-3 video streams in the Real-Time Transport
  30.    Protocol (RTP).  Each RTP packet contains all or a portion of one
  31.    scan line as defined by ITU Recommendation BT.601-5, and includes
  32.    fragmentation, decoding and positioning information.
  33.  
  34. 1. Introduction
  35.  
  36.    This document describes a scheme to packetize uncompressed, studio-
  37.    quality video streams as defined by BT.656 for transport using RTP
  38.    [1].  A BT.656 video stream is defined by ITU-R Recommendation
  39.    BT.656-3 [2], as a means of interconnecting digital television
  40.    equipment operating on the 525-line or 625-line standards, and
  41.    complying with the 4:2:2 encoding parameters as defined in ITU-R
  42.    Recommendation BT.601-5 (formerly CCIR-601) [3], Part A.
  43.  
  44.    RTP is defined by the Internet Engineering Task Force (IETF) to
  45.    provide end-to-end network transport functions suitable for
  46.    applications transmitting real-time data over multicast or unicast
  47.    network services.  The complete specification of RTP for a particular
  48.    application requires the RTP protocol document [1], a profile
  49.    specification document [4], and a payload format specification.  This
  50.    document is intended to serve as the payload format specification for
  51.    studio-quality video streams.
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Tynan                       Standards Track                     [Page 1]
  59.  
  60. RFC 2431             RTP Payload Format for BT.656          October 1998
  61.  
  62.  
  63.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  64.    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  65.    document are to be interpreted as described in RFC 2119 [5].
  66.  
  67. 2. Definitions
  68.  
  69.    For the purposes of this document, the following definitions apply:
  70.  
  71.    Y: An 8-bit or 10-bit coded "luminance" sample.  Luminance in this
  72.    context refers to the BT.601-5 [3] definition which is not the same
  73.    as a true CIE luminance value.  The value of "luminance" refers
  74.    specifically to video luma. However, in order to avoid confusion with
  75.    the BT.656 and BT.601 standards, the video luma value is referenced
  76.    in this document as luminance.  Each value has 220 quantization
  77.    levels with the black level corresponding to level 16 and the peak
  78.    white level corresponding to 235.
  79.  
  80.    Cb, Cr: An 8-bit or 10-bit coded color-difference sample (as per
  81.    BT.601-5).  Each color-difference value has 225 quantization levels
  82.    in the centre part of the quantization scale with a color-difference
  83.    of zero having an encoded value of 128.
  84.  
  85.    True Black: BT.601-5 defines a true black level as the quad-sample
  86.    sequence 0x80, 0x10, 0x80, 0x10, representing color-difference values
  87.    of 128 (0x80) and a luminance value of 16 (0x10).
  88.  
  89.    SAV, EAV: Video timing reference codes which appear at the start and
  90.    end of a BT.656 scan line.
  91.  
  92. 3. Payload Design
  93.  
  94.    ITU Recommendation BT.656-3 defines a schema for the digital
  95.    interconnection of television video signals in conjunction with
  96.    BT.601-5 which defines the digital representation of the original
  97.    analog signal.  While BT.601-5 refers to images with or without color
  98.    subsampling, the interconnection standard (BT.656-3) specifically
  99.    requires 4:2:2 subsampling. This specification also requires 4:2:2
  100.    subsampling such that the luminance stream occupies twice the
  101.    bandwidth of each of the two color-difference streams.  For normal
  102.    4:3 aspect ratio images, this results in 720 luminance samples per
  103.    scan line, and 360 samples of each of the two chrominance channels.
  104.    The total number of samples per scan line in this case is 1440.
  105.    While this payload format specification can accomodate various image
  106.    sizes and frame rates, only those in accordance with BT.601-5 are
  107.    currently supported.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Tynan                       Standards Track                     [Page 2]
  115.  
  116. RFC 2431             RTP Payload Format for BT.656          October 1998
  117.  
  118.  
  119.    Due to the lack of any form of video compression within the payload
  120.    and sampling-rate compliance with BT.601-5, the resultant video
  121.    stream can be considered "studio quality".  However, such a stream
  122.    can require approximately 20 megabytes per second of network
  123.    bandwidth.  In order to maximize packet size within a given MTU, and
  124.    to optimize scan line decoding, each video scan line is encoded
  125.    within one or more RTP packets.
  126.  
  127.    To allow for scan line synchronization, each packet includes certain
  128.    flag bits (as defined in BT.656-3) and a unique scan line number.
  129.    The SAV and EAV timing reference codes are removed. Furthermore, no
  130.    line blanking samples are included, so no ancillary data can be
  131.    included in the line blanking period.  It is the responsibility of
  132.    the receiver to generate the timing reference codes, and to insert
  133.    the correct number of line blanking samples.
  134.  
  135.    Similarly, there is no requirement that the frame blanking samples be
  136.    provided.  However, it is possible to include frame blanking samples
  137.    if such samples contain relevant information, such as a vertical-
  138.    interlace time code (VITC), or teletext data.  In the absence of
  139.    frame blanking samples, the receiver MUST generate true black levels
  140.    as defined above, to complete the correct number of scan lines per
  141.    field.  If frame blanking samples are provided, they MUST be copied
  142.    without modification into the resultant BT.656-3 stream.
  143.  
  144.    Scan lines MUST be sent in sequential order.  Error concealment for
  145.    missing scan lines or fragments of scan lines is at the discretion of
  146.    the receiver.
  147.  
  148.    Both 8-bit and 10-bit quantization types as defined by BT.601-5 are
  149.    supported.  10-bit samples are considered to have two extra bits of
  150.    fixed-point precision such that a binary value of 10111110.11
  151.    represents a sample value of 190.75.  Using 8-bit quantization, this
  152.    would give a sample value of 190.  An application receiving 8-bit
  153.    samples for a 10-bit device MUST consider the sample as reflecting
  154.    the most-significant 8 bits.  The two least-significant bits SHOULD
  155.    be set to zero.  Similarly, an application sending 8-bit samples from
  156.    a 10-bit device MUST drop the two least-significant bits.  For a 10-
  157.    bit quantization payload, each pair of samples MUST be encoded into a
  158.    40-bit word (five octets) prior to transmission, as specified in
  159.    Section 6.
  160.  
  161.    To allow for scan lines with octet lengths larger than the path
  162.    maximum transmission unit (MTU), a scan offset field is included in
  163.    the packet header.  Applications SHOULD attempt path MTU discovery
  164.    [6] and fragment scan lines into multiple packets no larger than the
  165.    MTU.
  166.  
  167.  
  168.  
  169.  
  170. Tynan                       Standards Track                     [Page 3]
  171.  
  172. RFC 2431             RTP Payload Format for BT.656          October 1998
  173.  
  174.  
  175.    Fragmentation MUST occur on a sample-pair boundary, such that the
  176.    chrominance and luminance values are not split across packets.  For
  177.    8-bit quantization this gives a four-octet alignment, and a five-
  178.    octet alignment for 10-bit quantization.  As a result, the scan
  179.    offset refers not to the byte offset within the payload, but the
  180.    sample-pair offset.
  181.  
  182. 4. Usage of RTP
  183.  
  184.    Due to the unreliable nature of the RTP protocol, and the lack of an
  185.    orderly delivery mechanism, each packet contains enough information
  186.    to form a single scan line without reference to prior scan lines or
  187.    prior frames.  In addition to the RTP header, a fixed length payload
  188.    header is included in each packet.  This header is four octets in
  189.    length.
  190.  
  191.        0                   1                   2                   3
  192.        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
  193.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  194.       |                           RTP Header                          |
  195.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  196.       |                         Payload Header                        |
  197.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  198.       |                          Payload Data                         |
  199.       |                                .                              |
  200.       |                                .                              |
  201.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  202.  
  203. 4.1. RTP Header usage
  204.  
  205.    Each RTP packet starts with a fixed RTP header.  The following fields
  206.    of the RTP fixed header are used for BT.656-3 encapsulation:
  207.  
  208.    Marker bit (M): The Marker bit of the RTP header is set to 1 for the
  209.    last packet of a frame (or the last fragment of the last scan line if
  210.    fragmented), and set to 0 on all other packets.
  211.  
  212.    Payload Type (PT): The Payload Type indicates the use of the payload
  213.    format defined in this document.  A profile MAY assign a payload type
  214.    value for this format either statically or dynamically as described
  215.    in RFC 1890 [4].
  216.  
  217.    Timestamp: The RTP Timestamp encodes the sampling instant of the
  218.    video frame currently being rendered.  All scan line packets within
  219.    the same frame will have the same timestamp.  The timestamp SHOULD
  220.    refer to the 'Ov' field synchronization point of the first field.
  221.    For the payload format defined by this document, the RTP timestamp is
  222.    based on a 90kHz clock.
  223.  
  224.  
  225.  
  226. Tynan                       Standards Track                     [Page 4]
  227.  
  228. RFC 2431             RTP Payload Format for BT.656          October 1998
  229.  
  230.  
  231. 5. Payload Header
  232.  
  233.    The payload header is a fixed four-octet header broken down as
  234.    follows:
  235.  
  236.        0                   1                   2                   3
  237.        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
  238.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  239.       |F|V| Type  |P| Z |     Scan Line (SL)    |  Scan Offset (SO)   |
  240.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  241.  
  242.    F: 1 bit
  243.    When 0, indicates the first field of a frame (line 4 through 265
  244.    inclusive for Type=0 or 2, and line 1 through 312 inclusive for Type=1
  245.    or 3).  Any other scan line is considered a component of the second
  246.    field, and the F bit will be set to 1.  This bit is copied directly
  247.    from the BT.656-compliant stream by the transmitter, and inserted into
  248.    the stream by the receiver.
  249.  
  250.    V: 1 bit
  251.    When 1, indicates that the scan line is part of the vertical interval.
  252.    Should always be 0 unless frame blanking data is sent.  In which case,
  253.    the V bit SHOULD be set to 1 for scan lines which do not form an
  254.    integral part of the image. This bit is copied directly from the
  255.    BT.656-compliant stream by the transmitter, and inserted into the
  256.    stream by the receiver.  For receivers which do not receive scan lines
  257.    during the vertical interval, BT.656 vertical interval data MUST be
  258.    generated by repeating the quad-sample sequence 0x80, 0x10, 0x80,
  259.    0x10, representing a true black level.
  260.  
  261.    Type: 4 bits
  262.    This field indicates the type of frame encoding within the payload.
  263.    It MUST remain unchanged for all scan lines within the same frame.
  264.    Currently only four types of encoding are defined.  These are as
  265.    follows;
  266.  
  267.       0 - NTSC (13.5MHz sample rate; 720 samples per line; 60 fields
  268.           per second; 525 lines per frame)
  269.  
  270.       1 - PAL (13.5MHz sample rate; 720 samples per line; 50 fields
  271.           per second; 625 lines per frame)
  272.  
  273.       2 - High Definition NTSC (18MHz sample rate; 1144 samples per
  274.           line; 60 fields per second; 525 lines per frame)
  275.  
  276.       3 - High Definition PAL (18MHz sample rate; 1152 samples per
  277.           line; 50 fields per second; 625 lines per frame)
  278.  
  279.  
  280.  
  281.  
  282. Tynan                       Standards Track                     [Page 5]
  283.  
  284. RFC 2431             RTP Payload Format for BT.656          October 1998
  285.  
  286.  
  287.    Further encodings can only be defined through the Internet Assigned
  288.    Numbers Authority (IANA).  For more information refer to Section 8,
  289.    "IANA Considerations".
  290.  
  291.    P: 1 bit
  292.    Indicates the required sample quantization size.  When 0, the payload
  293.    is comprised of 8-bit samples.  Otherwise, it carries 10-bit samples.
  294.    This bit MUST remain unchanged for all scan lines within the same
  295.    frame.
  296.  
  297.    Z: 2 bits
  298.    Reserved for future use.  Must be set to zero by the transmitter and
  299.    ignored by the receiver.
  300.  
  301.    Scan Line (SL): 12 bits
  302.    Indicates the scan line encapsulated in the payload.  Valid values
  303.    range from 1 through 625 inclusive. If no frame blanking data is
  304.    being transmitted, only scan lines 23 through 310 inclusive, and
  305.    lines 336 through 623 inclusive SHOULD be sent in the case of Type=1
  306.    or 3.  For 525/60 encoding (Type=0 or 2), scan lines 10 through 263
  307.    inclusive and lines 273 through 525 SHOULD be transmitted.
  308.  
  309.    If a receiver is generating a BT.656-3 data stream directly from this
  310.    packet, the F and V bits MUST be copied from the header rather than
  311.    being generated implicitly from the scan line number.  In the event
  312.    of a conflict, the F and V bits have precedence.
  313.  
  314.    Scan Offset (SO): 11 bits
  315.    Indicates the offset within the scan line for application-level
  316.    fragmentation.  After doing PMTU discovery, if the path MTU is less
  317.    than the required size for one complete scan line, the data SHOULD be
  318.    fragmented such that a given RTP packet does not exceed the allowable
  319.    MTU.  The offset for the first packet of a scan line MUST be set to
  320.    zero.  The scan offset refers to the sample-pair offset within the
  321.    scan such that for a scan line width of 720, the maximum scan offset
  322.    is 359.
  323.  
  324. 6. Payload Format
  325.  
  326.    In keeping with the 4:2:2 color subsampling of BT.656 and BT.601,
  327.    each pair of color-difference samples will be intermixed with two
  328.    luminance samples.  As per BT.656, the format for transmission SHALL
  329.    be Cb, Y, Cr, Y.  The following is a representation of a 720 sample
  330.    packet with 8-bit quantization:
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Tynan                       Standards Track                     [Page 6]
  339.  
  340. RFC 2431             RTP Payload Format for BT.656          October 1998
  341.  
  342.  
  343.        0                   1                   2                   3
  344.        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
  345.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  346.       |      Cb0      |      Y0       |      Cr0      |      Y1       |
  347.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  348.       |      Cb1      |      Y2       |      Cr1      |      Y3       |
  349.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  350.                                       .
  351.                                       .
  352.                                       .
  353.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  354.       |     Cb359     |     Y718      |     Cr359     |     Y719      |
  355.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  356.  
  357.    1144 and 1152 sample packets SHOULD increase the packet size
  358.    accordingly while maintaining the sample order.
  359.  
  360.    For 10-bit quantization, each group of four samples MUST be encoded
  361.    into a 40-bit word (five octets) prior to transmission.  The sample
  362.    order is identical to that for 8-bit quantization.  The following is
  363.    a representation of a 720 sample packet with 10-bit quantization:
  364.  
  365.                0         1         2         3
  366.                0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8
  367.               +---------+---------+---------+---------+
  368.               |   Cb0   |   Y0    |   Cr0   |   Y1    |
  369.               +---------+---------+---------+---------+
  370.               |   Cb1   |   Y2    |   Cr1   |   Y3    |
  371.               +---------+---------+---------+---------+
  372.                                   .
  373.                                   .
  374.                                   .
  375.               +---------+---------+---------+---------+
  376.               |  Cb359  |  Y718   |  Cr359  |  Y719   |
  377.               +---------+---------+---------+---------+
  378.                 (Note that the word width is 40 bits)
  379.               +-------+-------+-------+-------+-------+
  380.       Octets: |   0   |   1   |   2   |   3   |   4   |
  381.               +-------+-------+-------+-------+-------+
  382.  
  383.    The octets shown in these diagrams are transmitted in network byte
  384.    order, that is, left-to-right as shown.
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Tynan                       Standards Track                     [Page 7]
  395.  
  396. RFC 2431             RTP Payload Format for BT.656          October 1998
  397.  
  398.  
  399. 7. Security Considerations
  400.  
  401.    RTP packets using the payload format defined in this specification
  402.    are subject to the security considerations discussed in the RTP
  403.    specification [1].  This implies that confidentiality of the media
  404.    streams is achieved by encryption.  Because the payload format is
  405.    arranged end-to-end, encryption MAY be performed after encapsulation
  406.    so there is no conflict between the two operations.
  407.  
  408.    This payload type does not exhibit any significant non-uniformity in
  409.    the receiver side computational complexity for packet processing to
  410.    cause a potential denial-of-service threat.
  411.  
  412. 8. IANA Considerations
  413.  
  414.    The four encoding types defined by this document relate to specific
  415.    schema defined by ITU-R Recommendation BT.656-3.  Future revisions of
  416.    the recommendation may create further encoding types which need to be
  417.    supported over RTP. The "Type" field is four bits wide allowing for a
  418.    total of up to sixteen possible encodings, with twelve currently
  419.    reserved for future use.  Due to the small number of possible
  420.    encodings and given that it is very unlikely that future revisions of
  421.    BT.656 will introduce any new schema, requests to extend the Type
  422.    field MUST be vetted by the Internet Assigned Numbers Authority.
  423.    Furthermore, implementors SHOULD check the IANA repository for new
  424.    definitions of the Type field in order to comply with this document.
  425.  
  426.    Applications for a new Type value MUST be submitted to the IANA and
  427.    include the requestors name and contact information, the reason for
  428.    requesting a new Type and references to appropriate standards, such
  429.    as an updated version of ITU-R Recommendation BT.656.  Furthermore,
  430.    in the unlikely event that the new Type will lessen the security of a
  431.    compliant implementation, such security risk MUST be detailed in the
  432.    application.  The application will be reviewed by a Designated Expert
  433.    and if appropriate, a new Type will be assigned.  This type will be
  434.    listed in the IANA repository for future implementations.
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Tynan                       Standards Track                     [Page 8]
  451.  
  452. RFC 2431             RTP Payload Format for BT.656          October 1998
  453.  
  454.  
  455. 9. References
  456.  
  457.    [1]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
  458.          "RTP: A Transport Protocol for Real-Time Applications", RFC
  459.          1889, January 1996.
  460.  
  461.    [2]   Interfaces for Digital Component Video Signals in 525-Line and
  462.          625-Line Television Systems operating at the 4:2:2 Level of
  463.          Recommendation ITU-R BT.601 (Part A), ITU-R Recommendation
  464.          BT.656-3, 1995.
  465.  
  466.    [3]   Studio Encoding Parameters of Digital Television for Standard
  467.          4:3 and Wide-Screen 16:9 Aspect Ratios, ITU-R Recommendation
  468.          BT.601-5, 1995.
  469.  
  470.    [4]   Schulzrinne, H., "RTP Profile for Audio and Video Conference
  471.          with Minimal Control", RFC 1890, January 1996.
  472.  
  473.    [5]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
  474.          Levels", BCP 14, RFC 2119, March 1997.
  475.  
  476.    [6]   Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
  477.          November 1990.
  478.  
  479. 10. Author's Address
  480.  
  481.    Dermot Tynan
  482.    Claddagh Films Limited
  483.    3 White Oaks
  484.    Clybaun Road
  485.    Galway
  486.    Ireland
  487.  
  488.    EMail: dtynan@claddagh.ie
  489.    Phone: +353 91 529944
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Tynan                       Standards Track                     [Page 9]
  507.  
  508. RFC 2431             RTP Payload Format for BT.656          October 1998
  509.  
  510.  
  511. 11.  Full Copyright Statement
  512.  
  513.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  514.  
  515.    This document and translations of it may be copied and furnished to
  516.    others, and derivative works that comment on or otherwise explain it
  517.    or assist in its implementation may be prepared, copied, published
  518.    and distributed, in whole or in part, without restriction of any
  519.    kind, provided that the above copyright notice and this paragraph are
  520.    included on all such copies and derivative works.  However, this
  521.    document itself may not be modified in any way, such as by removing
  522.    the copyright notice or references to the Internet Society or other
  523.    Internet organizations, except as needed for the purpose of
  524.    developing Internet standards in which case the procedures for
  525.    copyrights defined in the Internet Standards process must be
  526.    followed, or as required to translate it into languages other than
  527.    English.
  528.  
  529.    The limited permissions granted above are perpetual and will not be
  530.    revoked by the Internet Society or its successors or assigns.
  531.  
  532.    This document and the information contained herein is provided on an
  533.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  534.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  535.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  536.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  537.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Tynan                       Standards Track                    [Page 10]
  563.  
  564.