RFC3556 日本語訳

3556 Session Description Protocol (SDP) Bandwidth Modifiers for RTPControl Protocol (RTCP) Bandwidth. S. Casner. July 2003. (Format: TXT=15310 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                          S. Casner
Request for Comments: 3556                                 Packet Design
Category: Standards Track                                      July 2003

Network Working Group S. Casner Request for Comments: 3556 Packet Design Category: Standards Track July 2003

         Session Description Protocol (SDP) Bandwidth Modifiers
               for RTP Control Protocol (RTCP) Bandwidth

Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth

Status of this Memo

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.

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 Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

Abstract

   This document defines an extension to the Session Description
   Protocol (SDP) to specify two additional modifiers for the bandwidth
   attribute.  These modifiers may be used to specify the bandwidth
   allowed for RTP Control Protocol (RTCP) packets in a Real-time
   Transport Protocol (RTP) session.

This document defines an extension to the Session Description Protocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTP Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP) session.

1.  Introduction

1. Introduction

   The Real-time Transport Protocol (RTP), RFC 3550 [1], includes a
   control protocol RTCP which provides synchronization information from
   data senders and feedback information from data receivers.

The Real-time Transport Protocol (RTP), RFC 3550 [1], includes a control protocol RTCP which provides synchronization information from data senders and feedback information from data receivers.

   Normally, the amount of bandwidth allocated to RTCP in an RTP session
   is 5% of the session bandwidth.  For some applications, it may be
   appropriate to specify the RTCP bandwidth independently of the
   session bandwidth.  Using a separate parameter allows rate-adaptive
   applications to set an RTCP bandwidth consistent with a "typical"
   data bandwidth that is lower than the maximum bandwidth specified by
   the session bandwidth parameter.  That allows the RTCP bandwidth to
   be kept under 5% of the data bandwidth when the rate has been adapted
   downward.

Normally, the amount of bandwidth allocated to RTCP in an RTP session is 5% of the session bandwidth. For some applications, it may be appropriate to specify the RTCP bandwidth independently of the session bandwidth. Using a separate parameter allows rate-adaptive applications to set an RTCP bandwidth consistent with a "typical" data bandwidth that is lower than the maximum bandwidth specified by the session bandwidth parameter. That allows the RTCP bandwidth to be kept under 5% of the data bandwidth when the rate has been adapted downward.

   On the other hand, there may be applications that send data at very
   low rates but need to communicate extra RTCP information, such as APP
   packets.  These applications may need to specify RTCP bandwidth that
   is higher than 5% of the data bandwidth.

On the other hand, there may be applications that send data at very low rates but need to communicate extra RTCP information, such as APP packets. These applications may need to specify RTCP bandwidth that is higher than 5% of the data bandwidth.

Casner                      Standards Track                     [Page 1]

RFC 3556       SDP Bandwidth Modifiers for RTCP Bandwidth      July 2003

Casner Standards Track [Page 1] RFC 3556 SDP Bandwidth Modifiers for RTCP Bandwidth July 2003

   The RTP specification allows a profile to specify that the RTCP
   bandwidth may be divided into two separate session parameters for
   those participants which are active data senders and those which are
   not.  Using two parameters allows RTCP reception reports to be turned
   off entirely for a particular session by setting the RTCP bandwidth
   for non-data-senders to zero while keeping the RTCP bandwidth for
   data senders non-zero so that sender reports can still be sent for
   inter-media synchronization.  Turning off RTCP reception reports is
   not recommended because they are needed for the functions listed in
   the RTP specification, particularly reception quality feedback and
   congestion control.  However, doing so may be appropriate for systems
   operating on unidirectional links or for sessions that do not require
   feedback on the quality of reception or liveness of receivers and
   that have other means to avoid congestion.

The RTP specification allows a profile to specify that the RTCP bandwidth may be divided into two separate session parameters for those participants which are active data senders and those which are not. Using two parameters allows RTCP reception reports to be turned off entirely for a particular session by setting the RTCP bandwidth for non-data-senders to zero while keeping the RTCP bandwidth for data senders non-zero so that sender reports can still be sent for inter-media synchronization. Turning off RTCP reception reports is not recommended because they are needed for the functions listed in the RTP specification, particularly reception quality feedback and congestion control. However, doing so may be appropriate for systems operating on unidirectional links or for sessions that do not require feedback on the quality of reception or liveness of receivers and that have other means to avoid congestion.

   This memo defines an extension to the Session Description Protocol
   (SDP) [3] to specify RTCP bandwidth for senders and non-senders
   (receivers).

This memo defines an extension to the Session Description Protocol (SDP) [3] to specify RTCP bandwidth for senders and non-senders (receivers).

2.  SDP Extensions

2. SDP Extensions

   The Session Description Protocol includes an optional bandwidth
   attribute with the following syntax:

The Session Description Protocol includes an optional bandwidth attribute with the following syntax:

      b=<modifier>:<bandwidth-value>

b=<modifier>:<bandwidth-value>

   where <modifier> is a single alphanumeric word giving the meaning of
   the bandwidth figure, and where the default units for <bandwidth-
   value> are kilobits per second.  This attribute specifies the
   proposed bandwidth to be used by the session or media.

where <modifier> is a single alphanumeric word giving the meaning of the bandwidth figure, and where the default units for <bandwidth- value> are kilobits per second. This attribute specifies the proposed bandwidth to be used by the session or media.

   A typical use is with the modifier "AS" (for Application Specific
   Maximum) which may be used to specify the total bandwidth for a
   single media stream from one site (source).

A typical use is with the modifier "AS" (for Application Specific Maximum) which may be used to specify the total bandwidth for a single media stream from one site (source).

   This memo defines two additional bandwidth modifiers:

This memo defines two additional bandwidth modifiers:

      b=RS:<bandwidth-value>

b=RS:<bandwidth-value>

      b=RR:<bandwidth-value>

b=RR:<bandwidth-value>

   where "RS" indicates the RTCP bandwidth allocated to active data
   senders (as defined by the RTP spec) and "RR" indicates the RTCP
   bandwidth allocated to other participants in the RTP session (i.e.,
   receivers).  The exact behavior induced by specifying these bandwidth
   modifiers depends upon the algorithm used to calculate the RTCP
   reporting interval.  Different algorithms may be specified by
   different RTP profiles.

where "RS" indicates the RTCP bandwidth allocated to active data senders (as defined by the RTP spec) and "RR" indicates the RTCP bandwidth allocated to other participants in the RTP session (i.e., receivers). The exact behavior induced by specifying these bandwidth modifiers depends upon the algorithm used to calculate the RTCP reporting interval. Different algorithms may be specified by different RTP profiles.

Casner                      Standards Track                     [Page 2]

RFC 3556       SDP Bandwidth Modifiers for RTCP Bandwidth      July 2003

Casner Standards Track [Page 2] RFC 3556 SDP Bandwidth Modifiers for RTCP Bandwidth July 2003

   For the RTP A/V Profile [2], which specifies that the default RTCP
   interval algorithm defined in the RTP spec [1] is to be used, at
   least RS/(RS+RR) of the RTCP bandwidth is dedicated to active data
   senders.  If the proportion of senders to total participants is less
   than or equal to RS/(RS+RR), each sender gets RS divided by the
   number of senders.  When the proportion of senders is greater than
   RS/(RS+RR), the senders get their proportion of the sum of these
   parameters, which means that a sender and a non-sender each get the
   same allocation.  Therefore, it is not possible to constrain the data
   senders to use less RTCP bandwidth than is allowed for non-senders.
   A few special cases are worth noting:

For the RTP A/V Profile [2], which specifies that the default RTCP interval algorithm defined in the RTP spec [1] is to be used, at least RS/(RS+RR) of the RTCP bandwidth is dedicated to active data senders. If the proportion of senders to total participants is less than or equal to RS/(RS+RR), each sender gets RS divided by the number of senders. When the proportion of senders is greater than RS/(RS+RR), the senders get their proportion of the sum of these parameters, which means that a sender and a non-sender each get the same allocation. Therefore, it is not possible to constrain the data senders to use less RTCP bandwidth than is allowed for non-senders. A few special cases are worth noting:

      o  If RR is zero, then the proportion of participants that are
         senders can never be greater than RS/(RS+RR), and therefore
         non-senders never get any RTCP bandwidth independent of the
         number of senders.

o If RR is zero, then the proportion of participants that are senders can never be greater than RS/(RS+RR), and therefore non-senders never get any RTCP bandwidth independent of the number of senders.

      o  Setting RS to zero does not mean that data senders are not
         allowed to send RTCP packets, it only means that they are
         treated the same as non-senders.  The proportion of senders (if
         there are any) would always be greater than RS/(RS+RR) if RR is
         non-zero.

o Setting RS to zero does not mean that data senders are not allowed to send RTCP packets, it only means that they are treated the same as non-senders. The proportion of senders (if there are any) would always be greater than RS/(RS+RR) if RR is non-zero.

      o  If RS and RR are both zero, it would be unwise to attempt
         calculation of the fraction RS/(RS+RR).

o If RS and RR are both zero, it would be unwise to attempt calculation of the fraction RS/(RS+RR).

   The bandwidth allocation specified by the RS and RR modifiers applies
   to the total bandwidth consumed by all RTCP packet types, including
   SR, RR, SDES, BYE, APP and any new types defined in the future.  The
   <bandwidth-value> for these modifiers is in units of bits per second
   with an integer value.

The bandwidth allocation specified by the RS and RR modifiers applies to the total bandwidth consumed by all RTCP packet types, including SR, RR, SDES, BYE, APP and any new types defined in the future. The <bandwidth-value> for these modifiers is in units of bits per second with an integer value.

      NOTE:  This specification was in conflict with the initial SDP
      spec in RFC 2327 which prescribes that the <bandwidth-value> for
      all bandwidth modifiers should be an integer number of kilobits
      per second.  This discrepancy was forced by the fact that the
      desired RTCP bandwidth setting may be less than 1 kb/s.

NOTE: This specification was in conflict with the initial SDP spec in RFC 2327 which prescribes that the <bandwidth-value> for all bandwidth modifiers should be an integer number of kilobits per second. This discrepancy was forced by the fact that the desired RTCP bandwidth setting may be less than 1 kb/s.

      At the 44th IETF meeting in Minneapolis, two solutions were
      considered: allow fractional values, or specify that the units for
      these particular modifiers would be in bits per second.  The
      second choice was preferred so that the syntax would not be
      changed.  The SDP spec is being modified [4] to advance to Draft
      Standard, and will allow this change in semantics.

At the 44th IETF meeting in Minneapolis, two solutions were considered: allow fractional values, or specify that the units for these particular modifiers would be in bits per second. The second choice was preferred so that the syntax would not be changed. The SDP spec is being modified [4] to advance to Draft Standard, and will allow this change in semantics.

Casner                      Standards Track                     [Page 3]

RFC 3556       SDP Bandwidth Modifiers for RTCP Bandwidth      July 2003

Casner Standards Track [Page 3] RFC 3556 SDP Bandwidth Modifiers for RTCP Bandwidth July 2003

3.  Default values

3. Default values

   If either or both of the RS and RR bandwidth specifiers are omitted,
   the default values for these parameters are as specified in the RTP
   profile in use for the session in question.  For the Audio/Video
   Profile, RFC 3551 [2], the defaults follow the recommendations of the
   RTP spec:

If either or both of the RS and RR bandwidth specifiers are omitted, the default values for these parameters are as specified in the RTP profile in use for the session in question. For the Audio/Video Profile, RFC 3551 [2], the defaults follow the recommendations of the RTP spec:

      o  The total RTCP bandwidth is 5% of the session bandwidth.  If
         one of these RTCP bandwidth specifiers is omitted, its value is
         5% minus the value of the other one, but not less than zero.
         If both are omitted, the sender and receiver RTCP bandwidths
         are 1.25% and 3.75% of the session bandwidth, respectively.

o The total RTCP bandwidth is 5% of the session bandwidth. If one of these RTCP bandwidth specifiers is omitted, its value is 5% minus the value of the other one, but not less than zero. If both are omitted, the sender and receiver RTCP bandwidths are 1.25% and 3.75% of the session bandwidth, respectively.

      o  At least RS/(RS+RR) of of the RTCP bandwidth is dedicated to
         active data senders.  When the proportion of senders is greater
         than RS/(RS+RR) of the participants, the senders get their
         proportion of the sum of these parameters.

o At least RS/(RS+RR) of of the RTCP bandwidth is dedicated to active data senders. When the proportion of senders is greater than RS/(RS+RR) of the participants, the senders get their proportion of the sum of these parameters.

   This memo does not impose limits on the values that may be specified
   with the RR and RS modifiers, other than that they must be non-
   negative.  However, the RTP specification and the appropriate RTP
   profile may specify limits.

This memo does not impose limits on the values that may be specified with the RR and RS modifiers, other than that they must be non- negative. However, the RTP specification and the appropriate RTP profile may specify limits.

4.  Precedence

4. Precedence

   An SDP description consists of a session-level description (details
   that apply to the whole session and all media streams) and zero or
   more media-level descriptions (details that apply only to a single
   media stream).  Bandwidth specifiers may be present either at the
   session level to specify the total bandwidth shared by all media, or
   in the media sections to specify the bandwidth allocated to each
   medium, or both.  This is true for the two RTCP bandwidth modifiers
   defined here as well.

An SDP description consists of a session-level description (details that apply to the whole session and all media streams) and zero or more media-level descriptions (details that apply only to a single media stream). Bandwidth specifiers may be present either at the session level to specify the total bandwidth shared by all media, or in the media sections to specify the bandwidth allocated to each medium, or both. This is true for the two RTCP bandwidth modifiers defined here as well.

   Since the bandwidth allocated to RTCP is a fraction of the session
   bandwidth when not specified explicitly using the modifiers defined
   here, there is an interaction between the session bandwidth and RTCP
   bandwidth specifiers at the session and media levels of the SDP
   description.  The precedence of these specifiers is as follows, with
   (1) being the highest precedence:

Since the bandwidth allocated to RTCP is a fraction of the session bandwidth when not specified explicitly using the modifiers defined here, there is an interaction between the session bandwidth and RTCP bandwidth specifiers at the session and media levels of the SDP description. The precedence of these specifiers is as follows, with (1) being the highest precedence:

   1) Explicit RR or RS specifier at media level

1) Explicit RR or RS specifier at media level

   2) Explicit RR or RS specifier at session level

2) Explicit RR or RS specifier at session level

   3) Default based on session bandwidth specifier at media level

3) Default based on session bandwidth specifier at media level

Casner                      Standards Track                     [Page 4]

RFC 3556       SDP Bandwidth Modifiers for RTCP Bandwidth      July 2003

Casner Standards Track [Page 4] RFC 3556 SDP Bandwidth Modifiers for RTCP Bandwidth July 2003

   4) Default based on session bandwidth specifier at session level

4) Default based on session bandwidth specifier at session level

   In particular, the relationship of (2) and (3) means that if the RR
   bandwidth is specified as zero at the session level, that turns off
   RTCP transmission for non-data-senders in all media.

In particular, the relationship of (2) and (3) means that if the RR bandwidth is specified as zero at the session level, that turns off RTCP transmission for non-data-senders in all media.

5.  Example

5. Example

   An example SDP description is:

An example SDP description is:

      v=0
      o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
      s=SDP Seminar
      i=A Seminar on the session description protocol
      c=IN IP4 224.2.17.12/127
      t=2873397496 2873404696
      m=audio 49170 RTP/AVP 0
      b=AS:64
      b=RS:800
      b=RR:2400
      m=video 51372 RTP/AVP 31
      b=AS:256
      b=RS:800
      b=RR:2400

v=0 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP Seminar i=A Seminar on the session description protocol c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 m=audio 49170 RTP/AVP 0 b=AS:64 b=RS:800 b=RR:2400 m=video 51372 RTP/AVP 31 b=AS:256 b=RS:800 b=RR:2400

   In this example, the explicit RTCP bandwidths for the audio medium
   are equal to the defaults and so could be omitted.  However, for the
   video medium, the RTCP bandwidths have been set according to a data
   bandwidth of 64 kb/s even though the maximum data bandwidth is
   specified as 256 kb/s.  This is based on the assumption that the
   video data bandwidth will automatically adapt to a lower value based
   on network conditions.

In this example, the explicit RTCP bandwidths for the audio medium are equal to the defaults and so could be omitted. However, for the video medium, the RTCP bandwidths have been set according to a data bandwidth of 64 kb/s even though the maximum data bandwidth is specified as 256 kb/s. This is based on the assumption that the video data bandwidth will automatically adapt to a lower value based on network conditions.

Casner                      Standards Track                     [Page 5]

RFC 3556       SDP Bandwidth Modifiers for RTCP Bandwidth      July 2003

Casner Standards Track [Page 5] RFC 3556 SDP Bandwidth Modifiers for RTCP Bandwidth July 2003

6.  IANA Considerations

6. IANA Considerations

   RFC 2327 [3] requires that new bandwidth modifiers be registered with
   IANA by reference to a standards-track RFC specifying the semantics
   of the bandwidth modifier precisely, indicating when it should be
   used, and why the existing registered bandwidth specifiers do not
   suffice.

RFC 2327 [3] requires that new bandwidth modifiers be registered with IANA by reference to a standards-track RFC specifying the semantics of the bandwidth modifier precisely, indicating when it should be used, and why the existing registered bandwidth specifiers do not suffice.

   This document is intended to satisfy those requirements.

This document is intended to satisfy those requirements.

   In the "bwtype" table of the Session Description Protocol (SDP)
   Parameters registry, the following two new bandwidth modifier names
   have been registered:

In the "bwtype" table of the Session Description Protocol (SDP) Parameters registry, the following two new bandwidth modifier names have been registered:

      RS
      RR

RS RR

7.  Security Considerations

7. Security Considerations

   This memo defines bandwidth modifier keywords as an extension to SDP,
   so the security considerations listed in the SDP specification apply
   to session descriptions containing these modifiers as with any other.

This memo defines bandwidth modifier keywords as an extension to SDP, so the security considerations listed in the SDP specification apply to session descriptions containing these modifiers as with any other.

   The bandwidth value supplied with one of these modifiers could be
   unreasonably large and cause the application to send RTCP packets at
   an excessive rate, resulting in a denial of service.  This is similar
   to the risk that an unreasonable bandwidth could be specified for the
   media data, though encoders generally have a limited bandwidth range.
   Applications should apply validity checks to all parameters received
   in an SDP description, particularly one which is not authenticated.
   This memo cannot specify limits because they are dependent on the RTP
   profile and application.

The bandwidth value supplied with one of these modifiers could be unreasonably large and cause the application to send RTCP packets at an excessive rate, resulting in a denial of service. This is similar to the risk that an unreasonable bandwidth could be specified for the media data, though encoders generally have a limited bandwidth range. Applications should apply validity checks to all parameters received in an SDP description, particularly one which is not authenticated. This memo cannot specify limits because they are dependent on the RTP profile and application.

8.  References

8. References

8.1  Normative References

8.1 Normative References

   [1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
       A Transport Protocol for Real-Time Applications," RFC 3550, July
       2003.

[1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications," RFC 3550, July 2003.

   [2] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
       Conferences with Minimal Control", RFC 3551, July 2003.

[2] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.

   [3] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
       RFC 2327, April 1998.

[3] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.

Casner                      Standards Track                     [Page 6]

RFC 3556       SDP Bandwidth Modifiers for RTCP Bandwidth      July 2003

Casner Standards Track [Page 6] RFC 3556 SDP Bandwidth Modifiers for RTCP Bandwidth July 2003

8.2  Informative References

8.2 Informative References

   [4] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session
       Description Protocol", Work in Progress.

[4] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", Work in Progress.

9.  Author's Address

9. Author's Address

   Stephen L. Casner
   Packet Design
   3400 Hillview Avenue, Building 3
   Palo Alto, CA 94304
   United States

Stephen L. Casner Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 United States

   Phone: +1 650 739-1843
   EMail: casner@acm.org

Phone: +1 650 739-1843 EMail: casner@acm.org

Casner                      Standards Track                     [Page 7]

RFC 3556       SDP Bandwidth Modifiers for RTCP Bandwidth      July 2003

Casner Standards Track [Page 7] RFC 3556 SDP Bandwidth Modifiers for RTCP Bandwidth July 2003

10.  Full Copyright Statement

10. Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright (C) The Internet Society (2003). 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.

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.

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.

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

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Funding for the RFC Editor function is currently provided by the Internet Society.

Casner                      Standards Track                     [Page 8]

Casner Standards Track [Page 8]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

SMARTY_CORE_DIR定数 Smartyのコアファイルのフルパス

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る