RFC3205 日本語訳
3205 On the use of HTTP as a Substrate. K. Moore. February 2002. (Format: TXT=34785 bytes) (Also BCP0056) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Moore Request for Comments: 3205 University of Tennessee BCP: 56 February 2002 Category: Best Current Practice
Network Working Group K. Moore Request for Comments: 3205 University of Tennessee BCP: 56 February 2002 Category: Best Current Practice
On the use of HTTP as a Substrate
On the use of HTTP as a Substrate
Status of this Memo
Status of this Memo
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
Abstract
Recently there has been widespread interest in using Hypertext Transfer Protocol (HTTP) as a substrate for other applications-level protocols. This document recommends technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms.
Recently there has been widespread interest in using Hypertext Transfer Protocol (HTTP) as a substrate for other applications-level protocols. This document recommends technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms.
1. Introduction
1. Introduction
Recently there has been widespread interest in using Hypertext Transfer Protocol (HTTP) [1] as a substrate for other applications- level protocols. Various reasons cited for this interest have included:
Recently there has been widespread interest in using Hypertext Transfer Protocol (HTTP) [1] as a substrate for other applications- level protocols. Various reasons cited for this interest have included:
o familiarity and mindshare,
o familiarity and mindshare,
o compatibility with widely deployed browsers,
o compatibility with widely deployed browsers,
o ability to reuse existing servers and client libraries,
o ability to reuse existing servers and client libraries,
o ease of prototyping servers using CGI scripts and similar
extension mechanisms,
o ease of prototyping servers using CGI scripts and similar extension mechanisms,
o ability to use existing security mechanisms such as HTTP digest
authentication [2] and SSL or TLS [3],
o ability to use existing security mechanisms such as HTTP digest authentication [2] and SSL or TLS [3],
o the ability of HTTP to traverse firewalls, and
o the ability of HTTP to traverse firewalls, and
o cases where a server often needs to support HTTP anyway.
o cases where a server often needs to support HTTP anyway.
Moore Best Current Practice [Page 1] RFC 3205 HTTP Layering February 2002
Moore Best Current Practice [Page 1] RFC 3205 HTTP Layering February 2002
The Internet community has a long tradition of protocol reuse, dating back to the use of Telnet [4] as a substrate for FTP [5] and SMTP [6]. However, the recent interest in layering new protocols over HTTP has raised a number of questions when such use is appropriate, and the proper way to use HTTP in contexts where it is appropriate. Specifically, for a given application that is layered on top of HTTP:
The Internet community has a long tradition of protocol reuse, dating back to the use of Telnet [4] as a substrate for FTP [5] and SMTP [6]. However, the recent interest in layering new protocols over HTTP has raised a number of questions when such use is appropriate, and the proper way to use HTTP in contexts where it is appropriate. Specifically, for a given application that is layered on top of HTTP:
o Should the application use a different port than the HTTP default
of 80?
o Should the application use a different port than the HTTP default of 80?
o Should the application use traditional HTTP methods (GET, POST,
etc.) or should it define new methods?
o Should the application use traditional HTTP methods (GET, POST, etc.) or should it define new methods?
o Should the application use http: URLs or define its own prefix?
o Should the application use http: URLs or define its own prefix?
o Should the application define its own MIME-types, or use something
that already exists (like registering a new type of MIME-directory
structure)?
o Should the application define its own MIME-types, or use something that already exists (like registering a new type of MIME-directory structure)?
This memo recommends certain design decisions in answer to these questions.
This memo recommends certain design decisions in answer to these questions.
This memo is intended as advice and recommendation for protocol designers, working groups, implementors, and IESG, rather than as a strict set of rules which must be adhered to in all cases. Accordingly, the capitalized key words defined in RFC 2119, which are intended to indicate conformance to a specification, are not used in this memo.
This memo is intended as advice and recommendation for protocol designers, working groups, implementors, and IESG, rather than as a strict set of rules which must be adhered to in all cases. Accordingly, the capitalized key words defined in RFC 2119, which are intended to indicate conformance to a specification, are not used in this memo.
2. Issues Regarding the Design Choice to use HTTP
2. Issues Regarding the Design Choice to use HTTP
Despite the advantages listed above, it's worth asking the question as to whether HTTP should be used at all, or whether the entire HTTP protocol should be used.
Despite the advantages listed above, it's worth asking the question as to whether HTTP should be used at all, or whether the entire HTTP protocol should be used.
2.1 Complexity
2.1 Complexity
HTTP started out as a simple protocol, but quickly became much more complex due to the addition of several features unanticipated by its original design. These features include persistent connections, byte ranges, content negotiation, and cache support. All of these are useful for traditional web applications but may not be useful for the layered application. The need to support (or circumvent) these features can add additional complexity to the design and implementation of a protocol layered on top of HTTP. Even when HTTP can be "profiled" to minimize implementation overhead, the effort of specifying such a profile might be more than the effort of specifying a purpose-built protocol which is better suited to the task at hand.
HTTP started out as a simple protocol, but quickly became much more complex due to the addition of several features unanticipated by its original design. These features include persistent connections, byte ranges, content negotiation, and cache support. All of these are useful for traditional web applications but may not be useful for the layered application. The need to support (or circumvent) these features can add additional complexity to the design and implementation of a protocol layered on top of HTTP. Even when HTTP can be "profiled" to minimize implementation overhead, the effort of specifying such a profile might be more than the effort of specifying a purpose-built protocol which is better suited to the task at hand.
Moore Best Current Practice [Page 2] RFC 3205 HTTP Layering February 2002
Moore Best Current Practice [Page 2] RFC 3205 HTTP Layering February 2002
Even if existing HTTP client and server code can often be re-used, the additional complexity of layering something over HTTP vs. using a purpose-built protocol can increase the number of interoperability problems.
Even if existing HTTP client and server code can often be re-used, the additional complexity of layering something over HTTP vs. using a purpose-built protocol can increase the number of interoperability problems.
2.2 Overhead
2.2 Overhead
Further, although HTTP can be used as the transport for a "remote procedure call" paradigm, HTTP's protocol overhead, along with the connection setup overhead of TCP, can make HTTP a poor choice. A protocol based on UDP, or with both UDP and TCP variants, should be considered if the payloads are very likely to be small (less than a few hundred bytes) for the foreseeable future. This is especially true if the protocol might be heavily used, or if it might be used over slow or expensive links.
Further, although HTTP can be used as the transport for a "remote procedure call" paradigm, HTTP's protocol overhead, along with the connection setup overhead of TCP, can make HTTP a poor choice. A protocol based on UDP, or with both UDP and TCP variants, should be considered if the payloads are very likely to be small (less than a few hundred bytes) for the foreseeable future. This is especially true if the protocol might be heavily used, or if it might be used over slow or expensive links.
On the other hand, the connection setup overhead can become negligible if the layered protocol can utilize HTTP/1.1's persistent connections, and if the same client and server are likely to perform several transactions during the time the HTTP connection is open.
On the other hand, the connection setup overhead can become negligible if the layered protocol can utilize HTTP/1.1's persistent connections, and if the same client and server are likely to perform several transactions during the time the HTTP connection is open.
2.3 Security
2.3 Security
Although HTTP appears at first glance to be one of the few "mature" Internet protocols that can provide good security, there are many applications for which neither HTTP's digest authentication nor TLS are sufficient by themselves.
Although HTTP appears at first glance to be one of the few "mature" Internet protocols that can provide good security, there are many applications for which neither HTTP's digest authentication nor TLS are sufficient by themselves.
Digest authentication requires a secret (e.g., a password) to be shared between client and server. This further requires that each client know the secret to be used with each server, but it does not provide any means of securely transmitting such secrets between the parties. Shared secrets can work fine for small groups where everyone is physically co-located; they don't work as well for large or dispersed communities of users. Further, if the server is compromised a large number of secrets may be exposed, which is especially dangerous if the same secret (or password) is used for several applications. (Similar concerns exist with TLS based clients or servers - if a private key is compromised then the attacker can impersonate the party whose key it has.)
Digest authentication requires a secret (e.g., a password) to be shared between client and server. This further requires that each client know the secret to be used with each server, but it does not provide any means of securely transmitting such secrets between the parties. Shared secrets can work fine for small groups where everyone is physically co-located; they don't work as well for large or dispersed communities of users. Further, if the server is compromised a large number of secrets may be exposed, which is especially dangerous if the same secret (or password) is used for several applications. (Similar concerns exist with TLS based clients or servers - if a private key is compromised then the attacker can impersonate the party whose key it has.)
TLS and its predecessor SSL were originally designed to authenticate web servers to clients, so that a user could be assured (for example) that his credit card number was not being sent to an imposter. However, many applications need to authenticate clients to servers, or to provide mutual authentication of client and server. TLS does
TLS and its predecessor SSL were originally designed to authenticate web servers to clients, so that a user could be assured (for example) that his credit card number was not being sent to an imposter. However, many applications need to authenticate clients to servers, or to provide mutual authentication of client and server. TLS does
Moore Best Current Practice [Page 3] RFC 3205 HTTP Layering February 2002
Moore Best Current Practice [Page 3] RFC 3205 HTTP Layering February 2002
have a capability to provide authentication in each direction, but such authentication may or may not be suitable for a particular application.
have a capability to provide authentication in each direction, but such authentication may or may not be suitable for a particular application.
Web browsers which support TLS or SSL are typically shipped with the public keys of several certificate authorities (CAs) "wired in" so that they can verify the identity of any server whose public key was signed by one of those CAs. For this to work well, every secure web server's public key has to be signed by one of the CAs whose keys are wired into popular browsers. This deployment model works when there are a (relatively) small number of servers whose identities can be verified, and their public keys signed, by the small number of CAs whose keys are included in a small number of different browsers.
Web browsers which support TLS or SSL are typically shipped with the public keys of several certificate authorities (CAs) "wired in" so that they can verify the identity of any server whose public key was signed by one of those CAs. For this to work well, every secure web server's public key has to be signed by one of the CAs whose keys are wired into popular browsers. This deployment model works when there are a (relatively) small number of servers whose identities can be verified, and their public keys signed, by the small number of CAs whose keys are included in a small number of different browsers.
This scheme does not work as well to authenticate millions of potential clients to servers. It would take a much larger number of CAs to do the job, each of which would need to be widely trusted by servers. Those CAs would also have a more difficult time verifying the identities of (large numbers of) ordinary users than they do in verifying the identities of (a smaller number of) commercial and other enterprises that need to run secure web servers.
This scheme does not work as well to authenticate millions of potential clients to servers. It would take a much larger number of CAs to do the job, each of which would need to be widely trusted by servers. Those CAs would also have a more difficult time verifying the identities of (large numbers of) ordinary users than they do in verifying the identities of (a smaller number of) commercial and other enterprises that need to run secure web servers.
Also, in a situation where there were a large number of clients authenticating with TLS, it seems unlikely that there would be a set of CAs whose keys were trusted by every server. A client that potentially needed to authenticate to multiple servers would therefore need to be configured as to which key to use with which server when attempting to establish a secure connection to the server.
Also, in a situation where there were a large number of clients authenticating with TLS, it seems unlikely that there would be a set of CAs whose keys were trusted by every server. A client that potentially needed to authenticate to multiple servers would therefore need to be configured as to which key to use with which server when attempting to establish a secure connection to the server.
For the reasons stated above, client authentication is rarely used with TLS. A common technique is to use TLS to authenticate the server to the client and to establish a private channel, and for the client to authenticate to the server using some other means - for example, a username and password using HTTP basic or digest authentication.
For the reasons stated above, client authentication is rarely used with TLS. A common technique is to use TLS to authenticate the server to the client and to establish a private channel, and for the client to authenticate to the server using some other means - for example, a username and password using HTTP basic or digest authentication.
For any application that requires privacy, the 40-bit ciphersuites provided by some SSL implementations (to conform to outdated US export regulations or to regulations on the use or export of cryptography in other countries) are unsuitable. Even 56-bit DES encryption, which is required of conforming TLS implementations, has been broken in a matter of days with a modest investment in resources. So if TLS is chosen it may be necessary to discourage use of small key lengths, or of weak ciphersuites, in order to provide adequate privacy assurance. If TLS is used to provide privacy for passwords sent by clients then it is especially important to support longer keys.
For any application that requires privacy, the 40-bit ciphersuites provided by some SSL implementations (to conform to outdated US export regulations or to regulations on the use or export of cryptography in other countries) are unsuitable. Even 56-bit DES encryption, which is required of conforming TLS implementations, has been broken in a matter of days with a modest investment in resources. So if TLS is chosen it may be necessary to discourage use of small key lengths, or of weak ciphersuites, in order to provide adequate privacy assurance. If TLS is used to provide privacy for passwords sent by clients then it is especially important to support longer keys.
Moore Best Current Practice [Page 4] RFC 3205 HTTP Layering February 2002
Moore Best Current Practice [Page 4] RFC 3205 HTTP Layering February 2002
None of the above should be taken to mean that either digest authentication or TLS are generally inferior to other authentication systems, or that they are unsuitable for use in other applications besides HTTP. Many of the limitations of TLS and digest authentication also apply to other authentication and privacy systems. The point here is that neither TLS nor digest authentication is a "magic pixie dust" solution to authentication or privacy. In every case, an application's designers must carefully determine the application's users' requirements for authentication and privacy before choosing an authentication or privacy mechanism.
None of the above should be taken to mean that either digest authentication or TLS are generally inferior to other authentication systems, or that they are unsuitable for use in other applications besides HTTP. Many of the limitations of TLS and digest authentication also apply to other authentication and privacy systems. The point here is that neither TLS nor digest authentication is a "magic pixie dust" solution to authentication or privacy. In every case, an application's designers must carefully determine the application's users' requirements for authentication and privacy before choosing an authentication or privacy mechanism.
Note also that TLS can be used with other TCP-based protocols, and there are SASL [7] mechanisms similar to HTTP's digest authentication. So it is not necessary to use HTTP in order to benefit from either TLS or digest-like authentication. However, HTTP APIs may already support TLS and/or digest.
Note also that TLS can be used with other TCP-based protocols, and there are SASL [7] mechanisms similar to HTTP's digest authentication. So it is not necessary to use HTTP in order to benefit from either TLS or digest-like authentication. However, HTTP APIs may already support TLS and/or digest.
2.4 Compatibility with Proxies, Firewalls, and NATs
2.4 Compatibility with Proxies, Firewalls, and NATs
One oft-cited reason for the use of HTTP is its ability to pass through proxies, firewalls, or network address translators (NATs). One unfortunate consequence of firewalls and NATs is that they make it harder to deploy new Internet applications, by requiring explicit permission (or even a software upgrade of the firewall or NAT) to accommodate each new protocol. The existence of firewalls and NATs creates a strong incentive for protocol designers to layer new applications on top of existing protocols, including HTTP.
One oft-cited reason for the use of HTTP is its ability to pass through proxies, firewalls, or network address translators (NATs). One unfortunate consequence of firewalls and NATs is that they make it harder to deploy new Internet applications, by requiring explicit permission (or even a software upgrade of the firewall or NAT) to accommodate each new protocol. The existence of firewalls and NATs creates a strong incentive for protocol designers to layer new applications on top of existing protocols, including HTTP.
However, if a site's firewall prevents the use of unknown protocols, this is presumably a conscious policy decision on the part of the firewall administrator. While it is arguable that such policies are of limited value in enhancing security, this is beside the point - well-known port numbers are quite useful for a variety of purposes, and the overloading of port numbers erodes this utility. Attempting to circumvent a site's security policy is not an acceptable justification for doing so.
However, if a site's firewall prevents the use of unknown protocols, this is presumably a conscious policy decision on the part of the firewall administrator. While it is arguable that such policies are of limited value in enhancing security, this is beside the point - well-known port numbers are quite useful for a variety of purposes, and the overloading of port numbers erodes this utility. Attempting to circumvent a site's security policy is not an acceptable justification for doing so.
It would be useful to establish guidelines for "firewall-friendly" protocols, to make it easier for existing firewalls to be compatible with new protocols.
It would be useful to establish guidelines for "firewall-friendly" protocols, to make it easier for existing firewalls to be compatible with new protocols.
2.5 Questions to be asked when considering use of HTTP
2.5 Questions to be asked when considering use of HTTP
o When considering payload size and traffic patterns, is HTTP an
appropriate transport for the anticipated use of this protocol?
o When considering payload size and traffic patterns, is HTTP an appropriate transport for the anticipated use of this protocol?
Moore Best Current Practice [Page 5] RFC 3205 HTTP Layering February 2002
Moore Best Current Practice [Page 5] RFC 3205 HTTP Layering February 2002
(In other words: will the payload size be worth the overhead
associated with TCP and HTTP? Or will the application be able to
make use of HTTP persistent connections to amortize the cost of
that overhead over several requests?)
(In other words: will the payload size be worth the overhead associated with TCP and HTTP? Or will the application be able to make use of HTTP persistent connections to amortize the cost of that overhead over several requests?)
o Is this new protocol usable by existing web browsers without
modification?
o Is this new protocol usable by existing web browsers without modification?
(For example: Is the request transmitted as if it were a filled-in
HTML form? Is the response which is returned viewable from a web
browser, say as HTML?)
(For example: Is the request transmitted as if it were a filled-in HTML form? Is the response which is returned viewable from a web browser, say as HTML?)
o Are the existing HTTP security mechanisms appropriate for the new
application?
o Are the existing HTTP security mechanisms appropriate for the new application?
o Are HTTP status codes and the HTTP status code paradigm suitable
for this application? (see section 8)
o Are HTTP status codes and the HTTP status code paradigm suitable for this application? (see section 8)
o Does the server for this application need to support HTTP anyway?
o Does the server for this application need to support HTTP anyway?
3. Issues Regarding Reuse of Port 80
3. Issues Regarding Reuse of Port 80
IANA has reserved TCP port number 80 for use by HTTP. It would not be appropriate for a substantially new service, even one which uses HTTP as a substrate, to usurp port 80 from its traditional use. A new use of HTTP might be considered a "substantially new service", thus requiring a new port, if any of the following are true:
IANA has reserved TCP port number 80 for use by HTTP. It would not be appropriate for a substantially new service, even one which uses HTTP as a substrate, to usurp port 80 from its traditional use. A new use of HTTP might be considered a "substantially new service", thus requiring a new port, if any of the following are true:
o The "new service" and traditional HTTP service are likely to
reference different sets of data, even when they both operate on
the same host.
o The "new service" and traditional HTTP service are likely to reference different sets of data, even when they both operate on the same host.
o There is a good reason for the "new service" to be implemented by
a separate server process, or separate code, than traditional HTTP
service on the same host, at least on some platforms.
o There is a good reason for the "new service" to be implemented by a separate server process, or separate code, than traditional HTTP service on the same host, at least on some platforms.
o There is a good reason to want to easily distinguish the traffic
of the "new service" from traditional HTTP, e.g., for the purposes
of firewall access control or traffic analysis.
o There is a good reason to want to easily distinguish the traffic of the "new service" from traditional HTTP, e.g., for the purposes of firewall access control or traffic analysis.
o If none of the above are true, it is arguable that the new use of
HTTP is an "extension" to traditional HTTP, rather than a "new
service". Extensions to HTTP which share data with traditional
HTTP services should probably define new HTTP methods to describe
those extensions, rather than using separate ports. If separate
ports are used, there is no way for a client to know whether they
are separate services or different ways of accessing the same
underlying service.
o If none of the above are true, it is arguable that the new use of HTTP is an "extension" to traditional HTTP, rather than a "new service". Extensions to HTTP which share data with traditional HTTP services should probably define new HTTP methods to describe those extensions, rather than using separate ports. If separate ports are used, there is no way for a client to know whether they are separate services or different ways of accessing the same underlying service.
Moore Best Current Practice [Page 6] RFC 3205 HTTP Layering February 2002
Moore Best Current Practice [Page 6] RFC 3205 HTTP Layering February 2002
4. Issues Regarding Reuse of the http: Scheme in URLs
4. Issues Regarding Reuse of the http: Scheme in URLs
A number of different URL schemes are in widespread use and many more are in the process of being standardized. In practice, the URL scheme not only serves as a "tag" to govern the interpretation of the remaining portion of the URL, it also provides coarse identification of the kind of resource or service which is being accessed. For example, web browsers typically provide a different response when a user mouse-clicks on an "http" URL, than when the user clicks on a "mailto" URL.
A number of different URL schemes are in widespread use and many more are in the process of being standardized. In practice, the URL scheme not only serves as a "tag" to govern the interpretation of the remaining portion of the URL, it also provides coarse identification of the kind of resource or service which is being accessed. For example, web browsers typically provide a different response when a user mouse-clicks on an "http" URL, than when the user clicks on a "mailto" URL.
Some criteria that might be used in making this determination are:
Some criteria that might be used in making this determination are:
o Whether this URL scheme is likely to become widely used, versus
used only in limited communities or by private agreement.
o Whether this URL scheme is likely to become widely used, versus used only in limited communities or by private agreement.
o Whether a new "default port" is needed. If reuse of port 80 is
not appropriate (see above), a new "default port" is needed. A
new default port in turn requires that a new URL scheme be
registered if that URL scheme is expected to be widely used.
Explicit port numbers in URLs are regarded as an "escape hatch",
not something for use in ordinary circumstances.
o Whether a new "default port" is needed. If reuse of port 80 is not appropriate (see above), a new "default port" is needed. A new default port in turn requires that a new URL scheme be registered if that URL scheme is expected to be widely used. Explicit port numbers in URLs are regarded as an "escape hatch", not something for use in ordinary circumstances.
o Whether use of the new service is likely to require a
substantially different setup or protocol interaction with the
server, than ordinary HTTP service. This could include the need
to request a different type of service from the network, or to
reserve bandwidth, or to present different TLS authentication
credentials to the server, or different kind of server
provisioning, or any number of other needs.
o Whether use of the new service is likely to require a substantially different setup or protocol interaction with the server, than ordinary HTTP service. This could include the need to request a different type of service from the network, or to reserve bandwidth, or to present different TLS authentication credentials to the server, or different kind of server provisioning, or any number of other needs.
o Whether user interfaces (such as web browsers) are likely to be
able to exploit the difference in the URL prefix to produce a
significant improvement in usability.
o Whether user interfaces (such as web browsers) are likely to be able to exploit the difference in the URL prefix to produce a significant improvement in usability.
According to the rules in [8] the "http:" URI is part of the "IETF Tree" for URL scheme names, and IETF is the maintainer of the "IETF Tree". Since IESG is the decision-making body for IETF, IESG has the authority to determine whether a resource accessed by a protocol that is layered on top of HTTP, should use http: or some other URL prefix.
According to the rules in [8] the "http:" URI is part of the "IETF Tree" for URL scheme names, and IETF is the maintainer of the "IETF Tree". Since IESG is the decision-making body for IETF, IESG has the authority to determine whether a resource accessed by a protocol that is layered on top of HTTP, should use http: or some other URL prefix.
Note that the convention of appending an "s" to the URL scheme to mean "use TLS or SSL" (as in "http:" vs "https:") is nonstandard and of limited value. For most applications, a single "use TLS or SSL" bit is not sufficient to adequately convey the information that a client needs to authenticate itself to a server, even if it has the proper credentials. For instance, in order to ensure that adequate security is provided with TLS an application may need to be
Note that the convention of appending an "s" to the URL scheme to mean "use TLS or SSL" (as in "http:" vs "https:") is nonstandard and of limited value. For most applications, a single "use TLS or SSL" bit is not sufficient to adequately convey the information that a client needs to authenticate itself to a server, even if it has the proper credentials. For instance, in order to ensure that adequate security is provided with TLS an application may need to be
Moore Best Current Practice [Page 7] RFC 3205 HTTP Layering February 2002
Moore Best Current Practice [Page 7] RFC 3205 HTTP Layering February 2002
configured with a list of acceptable ciphersuites, or with the client certificate to be used to authenticate to a particular server. When it is necessary to specify authentication or other connection setup information in a URL these should be communicated in URL parameters, rather than in the URL prefix.
configured with a list of acceptable ciphersuites, or with the client certificate to be used to authenticate to a particular server. When it is necessary to specify authentication or other connection setup information in a URL these should be communicated in URL parameters, rather than in the URL prefix.
5. Issues regarding use of MIME media types
5. Issues regarding use of MIME media types
Since HTTP uses the MIME media type system [9] to label its payload, many applications which layer on HTTP will need to define, or select, MIME media types for use by that application. Especially when using a multipart structure, the choice of media types requires careful consideration. In particular:
Since HTTP uses the MIME media type system [9] to label its payload, many applications which layer on HTTP will need to define, or select, MIME media types for use by that application. Especially when using a multipart structure, the choice of media types requires careful consideration. In particular:
o Should some existing framework be used, such as text/directory
[10], or XML [11,12], or should the new content-types be built
from scratch? Just as with HTTP, it's useful if code can be
reused, but protocol designers should not be over-eager to
incorporate a general but complex framework into a new protocol.
Experience with ASN.1, for example, suggests that the advantage of
using a general framework may not be worth the cost.
o Should some existing framework be used, such as text/directory [10], or XML [11,12], or should the new content-types be built from scratch? Just as with HTTP, it's useful if code can be reused, but protocol designers should not be over-eager to incorporate a general but complex framework into a new protocol. Experience with ASN.1, for example, suggests that the advantage of using a general framework may not be worth the cost.
o Should MIME multipart or message types be allowed? This can be an
advantage if it is desirable to incorporate (for example) the
multipart/alternative construct or the MIME security framework.
On the other hand, these constructs were designed specifically for
use in store-and-forward electronic mail systems, and other
mechanisms may be more appropriate for the application being
considered.
o Should MIME multipart or message types be allowed? This can be an advantage if it is desirable to incorporate (for example) the multipart/alternative construct or the MIME security framework. On the other hand, these constructs were designed specifically for use in store-and-forward electronic mail systems, and other mechanisms may be more appropriate for the application being considered.
The point here is that a decision to use MIME content-type names
to describe protocol payloads (which is generally desirable if the
same payloads may appear in other applications) does not imply
that the application must accept arbitrary MIME content-types,
including MIME multipart or security mechanisms. Nor does it
imply that the application must use MIME syntax or that it must
recognize or even tolerate existing MIME header fields.
The point here is that a decision to use MIME content-type names to describe protocol payloads (which is generally desirable if the same payloads may appear in other applications) does not imply that the application must accept arbitrary MIME content-types, including MIME multipart or security mechanisms. Nor does it imply that the application must use MIME syntax or that it must recognize or even tolerate existing MIME header fields.
o If the same payload is likely to be sent over electronic mail, the
differences between HTTP encoding of the payload and email
encoding of the payload should be minimized. Ideally, there
should be no differences in the "canonical form" used in the two
environments. Text/* media types can be problematic in this
regard because MIME email requires CRLF for line endings of text/*
body parts, where HTTP traditionally uses LF only.
o If the same payload is likely to be sent over electronic mail, the differences between HTTP encoding of the payload and email encoding of the payload should be minimized. Ideally, there should be no differences in the "canonical form" used in the two environments. Text/* media types can be problematic in this regard because MIME email requires CRLF for line endings of text/* body parts, where HTTP traditionally uses LF only.
Moore Best Current Practice [Page 8] RFC 3205 HTTP Layering February 2002
Moore Best Current Practice [Page 8] RFC 3205 HTTP Layering February 2002
o A MIME content-type label describes the nature of the object being
labeled. It does not describe, and should not be used to
describe, the semantics which should be applied when the object is
received. For instance, the transmission of an object with a
particular content-type using HTTP POST, should not be taken as a
request for some operation based solely on the type. The request
should be separate from the content-type label and it should be
explicit.
o A MIME content-type label describes the nature of the object being labeled. It does not describe, and should not be used to describe, the semantics which should be applied when the object is received. For instance, the transmission of an object with a particular content-type using HTTP POST, should not be taken as a request for some operation based solely on the type. The request should be separate from the content-type label and it should be explicit.
When it is necessary for a protocol layered on HTTP to allow
different operations on the same type of object, this can be
communicated in a number of different ways: HTTP methods, HTTP
request-URI, HTTP request headers, the MIME Content-Disposition
header field, or as part of the payload.
When it is necessary for a protocol layered on HTTP to allow different operations on the same type of object, this can be communicated in a number of different ways: HTTP methods, HTTP request-URI, HTTP request headers, the MIME Content-Disposition header field, or as part of the payload.
6. Issues Regarding Existing vs. New HTTP Methods
6. Issues Regarding Existing vs. New HTTP Methods
It has been suggested that a new service layered on top of HTTP should define one or more new HTTP methods, rather than allocating a new port. The use of new methods may be appropriate, but is not sufficient in all cases. The definition of one or more new methods for use in a new protocol, does not by itself alleviate the need for use of a new port, or a new URL type.
It has been suggested that a new service layered on top of HTTP should define one or more new HTTP methods, rather than allocating a new port. The use of new methods may be appropriate, but is not sufficient in all cases. The definition of one or more new methods for use in a new protocol, does not by itself alleviate the need for use of a new port, or a new URL type.
7. Issues regarding reuse of HTTP client, server, and proxy code
7. Issues regarding reuse of HTTP client, server, and proxy code
As mentioned earlier, one of the primary reasons for the use of HTTP as a substrate for new protocols, is to allow reuse of existing HTTP client, server, or proxy code. However, HTTP was not designed for such layering. Existing HTTP client and code may have "http" assumptions wired into them. For instance, client libraries and proxies may expect "http:" URLs, and clients and servers may send (and expect) "HTTP/1.1", in requests and responses, as opposed to the name of the layered protocol and its version number.
As mentioned earlier, one of the primary reasons for the use of HTTP as a substrate for new protocols, is to allow reuse of existing HTTP client, server, or proxy code. However, HTTP was not designed for such layering. Existing HTTP client and code may have "http" assumptions wired into them. For instance, client libraries and proxies may expect "http:" URLs, and clients and servers may send (and expect) "HTTP/1.1", in requests and responses, as opposed to the name of the layered protocol and its version number.
Existing client libraries may not understand new URL types. In order to get a new HTTP-layered application client to work with an existing client library, it may be necessary for the application to convert its URLs to an "http equivalent" form. For instance, if service "xyz" is layered on top of HTTP using port ###, the xyz client may need, when invoking an HTTP client library, to translate its URLs from "xyz://host/something" format to "http://host:###/something" for the purpose of calling that library. This should be done ONLY when calling the HTTP client library - such URLs should not be used in other parts of the protocol, nor should they be exposed to users.
Existing client libraries may not understand new URL types. In order to get a new HTTP-layered application client to work with an existing client library, it may be necessary for the application to convert its URLs to an "http equivalent" form. For instance, if service "xyz" is layered on top of HTTP using port ###, the xyz client may need, when invoking an HTTP client library, to translate its URLs from "xyz://host/something" format to "http://host:###/something" for the purpose of calling that library. This should be done ONLY when calling the HTTP client library - such URLs should not be used in other parts of the protocol, nor should they be exposed to users.
Moore Best Current Practice [Page 9] RFC 3205 HTTP Layering February 2002
Moore Best Current Practice [Page 9] RFC 3205 HTTP Layering February 2002
Note that when a client is sending requests directly to an origin
server, the URL prefix ("http:") is not normally sent. So
translating xyz: URLs to http: URLs when calling the client library
should not actually cause http: URLs to be sent over the wire. But
when the same client is sending requests to a proxy server, the
client will normally send the entire URL (including the http: prefix)
in those requests. The proxy will remove the http: prefix when the
request is communicated to the origin server.
Note that when a client is sending requests directly to an origin server, the URL prefix ("http:") is not normally sent. So translating xyz: URLs to http: URLs when calling the client library should not actually cause http: URLs to be sent over the wire. But when the same client is sending requests to a proxy server, the client will normally send the entire URL (including the http: prefix) in those requests. The proxy will remove the http: prefix when the request is communicated to the origin server.
Existing HTTP client libraries and servers will transmit "HTTP/1.1" (or a different version) in requests and responses. To facilitate reuse of such libraries and servers by a new protocol, such a protocol may therefore need to transmit and accept "HTTP/1.1" rather than its own protocol name and version number. Designers of protocols which are layered on top of HTTP should explicitly choose whether or not to accept "HTTP/1.1" in protocol exchanges.
Existing HTTP client libraries and servers will transmit "HTTP/1.1" (or a different version) in requests and responses. To facilitate reuse of such libraries and servers by a new protocol, such a protocol may therefore need to transmit and accept "HTTP/1.1" rather than its own protocol name and version number. Designers of protocols which are layered on top of HTTP should explicitly choose whether or not to accept "HTTP/1.1" in protocol exchanges.
For certain applications it may be necessary to require or limit use of certain HTTP features, for example, to defeat caching of responses by proxies. Each protocol layered on HTTP must therefore specify the specific way that HTTP will be used, and in particular, how the client and server should interact with HTTP proxies.
For certain applications it may be necessary to require or limit use of certain HTTP features, for example, to defeat caching of responses by proxies. Each protocol layered on HTTP must therefore specify the specific way that HTTP will be used, and in particular, how the client and server should interact with HTTP proxies.
8. Issues regarding use of HTTP status codes
8. Issues regarding use of HTTP status codes
HTTP's three-digit status codes were designed for use with traditional HTTP applications (e.g., document retrieval, forms-based queries), and are unlikely to be suitable to communicate the specifics of errors encountered in dissimilar applications. Even when it seems like there is a close match between HTTP status codes and the codes needed by the application, experience with reuse of other protocols indicates that subtle variations in usage are likely; and that this is likely to degrade interoperability of both the original protocol (in this case HTTP) and any layered applications.
HTTPの3ケタのステータスコードは、使用のために伝統的なHTTPアプリケーション(例えば、検索を記録してください、フォームベースの質問)で設計されて、異なったアプリケーションで遭遇する誤りの詳細を伝えるのにおいて適当でありそうにはありません。 HTTPステータスコードとアプリケーションで必要であるコードの間には、互角の試合があるように見えると、他のプロトコルの再利用の経験は、用法におけるわずかな変更がありそうであることを示します。 そして、これはオリジナルのプロトコル(この場合HTTP)とどんな層にされたアプリケーションの両方の相互運用性も下がらせそうです。
HTTP status codes therefore should not be used to indicate subtle errors of layered applications. At most, the "generic" HTTP codes 200 (for complete success) and 500 (for complete failure) should be used to indicate errors resulting from the content of the request message-body. Under certain circumstances, additional detail about the nature of the error can then be included in the response message-body. Other status codes than 200 or 500 should only appear if the error was detected by the HTTP server or by an intermediary.
したがって、層にされたアプリケーションの微妙な誤りを示すのにHTTPステータスコードを使用するべきではありません。 高々、「ジェネリック」HTTPコード200(完全な成功のための)と500(完全な失敗のための)は、要求メッセージ本体の内容から生じる誤りを示すのに使用されるべきです。 そして、ある状況で、応答メッセージ本体に誤りの本質に関する追加詳細を含むことができます。 誤りがHTTPサーバか仲介者によって検出される場合にだけ、200か500以外のステータスコードは現れるでしょうに。
A layered application should not define new HTTP status codes. The set of available status codes is small, conflicts in code assignment between different layered applications are likely, and they may be needed by future versions of, or extensions to, mainstream HTTP.
層にされたアプリケーションは新しいHTTPステータスコードを定義するべきではありません。 利用可能なステータスコードのセットが小さく、異なった層にされたアプリケーションの間のコード課題における闘争がありそうであり、それらが将来のバージョンによって必要とされるかもしれない、拡大、HTTPを主流に組み入れてください。
Moore Best Current Practice [Page 10] RFC 3205 HTTP Layering February 2002
2002年2月に層にされるムーア最も良い現在の習慣[10ページ]RFC3205HTTP
Use of HTTP's error codes is problematic when the layered application does not share same notion of success or failure as HTTP. The problem exists when the client does not connect directly to the origin server, but via one or more HTTP caches or proxies. (Since the ability of HTTP to communicate through intermediaries is often the primary motivation for reusing HTTP, the ability of the application to operate in the presence of such intermediaries is considered very important.) Such caches and proxies will interpret HTTP's error codes and may take additional action based on those codes. For instance, on receipt of a 200 error code from an origin server (and under other appropriate conditions) a proxy may cache the response and re-issue it in response to a similar request. Or a proxy may modify the result of a request which returns a 500 error code in order to add a "helpful" error message. Other response codes may produce other behaviors.
層にされたアプリケーションがHTTPとしての成否の同じ概念を共有しないとき、HTTPのエラーコードの使用は問題が多いです。 クライアントが直接発生源サーバに接続するのではなく、1つ以上のHTTPキャッシュかプロキシを通して接続するとき、問題は存在しています。 (しばしばHTTPが仲介者を通って交信する能力がHTTPを再利用することに関するプライマリ動機であるので、アプリケーションがそのような仲介者の面前で作動する能力は非常に重要であると考えられます。) そのようなキャッシュとプロキシは、HTTPのエラーコードを解釈して、それらのコードに基づく追加措置を取るかもしれません。 例えば、発生源サーバ(そして他の適切な状態の下で)からの200エラーコードを受け取り次第、プロキシは、応答をキャッシュして、同様の要求に対応してそれを再発行するかもしれません。 または、プロキシは「役立っている」エラーメッセージを加えるために500エラーコードを返す要求の結果を変更するかもしれません。 他の応答コードは他の振舞いを起こすかもしれません。
A few guidelines are therefore in order:
したがって、いくつかのガイドラインが整然としています:
o A layered application should use appropriate HTTP error codes to
report errors resulting from information in the HTTP request-line
and header fields associated with the request. This request
information is part of the HTTP protocol and errors which are
associated with that information should therefore be reported
using HTTP protocol mechanisms.
o 層にされたアプリケーションは、HTTP要求系列における情報から生じる誤りと要求に関連しているヘッダーフィールドを報告するのに適切なHTTPエラーコードを使用するべきです。 この要求情報はHTTPプロトコルの一部です、そして、したがって、その情報に関連している誤りは、HTTPプロトコルメカニズムを使用することで報告されるべきです。
o A layered application for which all errors resulting from the
message-body can be classified as either "complete success" or
"complete failure" may use 200 and 500 for those conditions,
respectively. However, the specification for such an application
must define the mechanism which ensures that its successful (200)
responses are not cached by intermediaries, or demonstrate that
such caching will do no harm; and it must be able to operate even
if the message-body of an error (500) response is not transmitted
back to the client intact.
o 「完全な成功」か「完全な失敗」のどちらかとしてメッセージ本体から生じるすべての誤りを分類できる層にされたアプリケーションはそれらの状態にそれぞれ200と500を使用するかもしれません。 しかしながら、そのようなアプリケーションのための仕様は、うまくいっている(200)応答が仲介者によってキャッシュされないのを確実にするメカニズムを定義しなければならないか、またはそのようなキャッシュに危害を加えないのをデモをしなければなりません。 そして、誤り(500)応答のメッセージ本体がクライアントに完全な状態で伝えて戻されないでも、作動できなければなりません。
o A layered application may return a 200 response code for both
successfully processed requests and errors (or other exceptional
conditions) resulting from the request message-body (but not from
the request headers). Such an application must return its error
code as part of the response message body, and the specification
for that application protocol must define the mechanism by which
the application ensures that its responses are not cached by
intermediaries. In this case a response other than 200 should be
used only to indicate errors with, or the status of, the HTTP
protocol layer (including the request headers), or to indicate the
inability of the HTTP server to communicate with the application
server.
o 層にされたアプリケーションは、首尾よく処理された要求と誤り(または、他の例外的な状態)の両方のために要求メッセージ本体(しかし、いずれの要求ヘッダーからも、そうしない)から生じながら、200応答コードを返すかもしれません。 そのようなアプリケーションは応答メッセージ身体の一部としてエラーコードを返さなければなりません、そして、そのアプリケーション・プロトコルのための仕様はアプリケーションが、応答が仲介者によってキャッシュされないのを確実にするメカニズムを定義しなければなりません。 この場合200以外の応答が単に誤りを示すのにおいて使用されていて状態であるべきである、HTTPプロトコル層(要求ヘッダーを含んでいる)、HTTPサーバがアプリケーション・サーバーとコミュニケートできないことを示します。
Moore Best Current Practice [Page 11] RFC 3205 HTTP Layering February 2002
2002年2月に層にされるムーア最も良い現在の習慣[11ページ]RFC3205HTTP
o A layered application which cannot operate in the presence of
intermediaries or proxies that cache and/or alter error responses,
should not use HTTP as a substrate.
o 仲介者かプロキシの面前でそのキャッシュを操作する、そして/または、誤り応答を変更できない層にされたアプリケーション、基板としてHTTPを使用するべきではありません。
9. Summary of recommendations regarding reuse of HTTP
9. HTTPの再利用に関する推薦の概要
1. All protocols should provide adequate security. The security
needs of a particular application will vary widely depending on
the application and its anticipated use environment. Merely using
HTTP and/or TLS as a substrate for a protocol does not
automatically provide adequate security for all environments, nor
does it relieve the protocol developers of the need to analyze
security considerations for their particular application.
1. すべてのプロトコルが十分な安全性を提供するべきです。 アプリケーションによって、特定用途の安全要求はばらつきが大きいでしょう、そして、それは環境を使用するように予期しました。 プロトコルに基板として単にHTTP、そして/または、TLSを使用するのは自動的にすべての環境に十分な安全性を提供しません、そして、それは彼らの特定用途のためにセキュリティ問題を分析する必要性をプロトコル開発者に取り除きません。
2. New protocols - including but not limited to those using HTTP -
should not attempt to circumvent users' firewall policies,
particularly by masquerading as existing protocols.
"Substantially new services" should not reuse existing ports.
2. 新しいプロトコル----ものがHTTPを使用して、他を含んでいて、ユーザのファイアウォール方針を回避するのを特に既存のプロトコルのふりをすることによって、試みるべきではありません。 「実質的に新しいサービス」は既存のポートを再利用するべきではありません。
3. In general, new protocols or services should not reuse http: or
other URL schemes.
3. 一般に、新しいプロトコルかサービスがhttpを再利用するべきではありません: または、他のURL体系。
4. Each new protocol specification that uses HTTP as a substrate
should describe the specific way that HTTP is to be used by that
protocol, including how the client and server interact with
proxies.
4. 基板としてHTTPを使用するそれぞれの新しいプロトコル仕様はそのプロトコルによって使用されるHTTPがことである特定の方法を述べるべきです、クライアントとサーバがどうプロキシと対話するかを含んでいて。
5. New services should follow the guidelines in section 8 regarding
use of HTTP status codes.
5. 新種業務はHTTPステータスコードの使用に関するセクション8でガイドラインに従うべきです。
10. Security Considerations
10. セキュリティ問題
Much of this document is about security. Section 2.3 discusses whether HTTP security is adequate for the needs of a particular application, section 2.4 discusses interactions between new HTTP- based protocols and firewalls, section 3 discusses use of separate ports so that firewalls are not circumvented, and section 4 discusses the inadequacy of the "s" suffix of a URL prefix for specifying security levels.
このドキュメントの多くがセキュリティに関するものです。 セクション2.3は、特定用途の必要性に、HTTPセキュリティが適切であるかどうか論じます、そして、セクション2.4は新しいHTTPベースのプロトコルとファイアウォールとの相互作用について論じます、そして、セクション3が別々のポートの使用について論ずるので、ファイアウォールは回避されません、そして、セクション4はセキュリティー・レベルを指定するためにURL接頭語の「s」接尾語の不適当について論じます。
11. References
11. 参照
[1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[1] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
Moore Best Current Practice [Page 12] RFC 3205 HTTP Layering February 2002
2002年2月に層にされるムーア最も良い現在の習慣[12ページ]RFC3205HTTP
[2] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[2] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[3] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[4] Postel, J. and J. Reynolds, "Telnet Protocol Specification",
STD 8, RFC 854, May 1983.
[4] ポステルとJ.とJ.レイノルズ、「telnetプロトコル仕様」、STD8、RFC854、1983年5月。
[5] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
RFC 959, October 1985.
[5] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、1985年10月。
[6] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
2001.
[6]Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[7] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
[7] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。
[8] Petke, R. and I. King, "Registration Procedures for URL Scheme
Names", BCP 35, RFC 2717, November 1999.
[8]Petke、R.とI.キング、「URL体系名のための登録手順」BCP35、1999年11月のRFC2717。
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
解放された[9]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[10] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type for
Directory Information", RFC 2425, September 1998.
[10] ハウズとT.とスミスとM.とF.ドーソン、「ディレクトリ情報のためのMIMEコンテントタイプ」、RFC2425、1998年9月。
[11] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup
Language (XML)" World Wide Web Consortium Recommendation REC-
xml-19980210, February 1998. http://www.w3.org/TR/1998/REC-
xml-19980210.
[11] T.とパオリとJ.とC.Sperberg-マックィーン、「拡張マークアップ言語(XML)」ワールドワイドウェブコンソーシアムRecommendation REC- xml-19980210をいななかせてください、2月1998日の http://www.w3.org/TR/1998/REC- xml-19980210。
[12] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[12] ムラタとM.と聖ローランとS.とD.コーン、「XMLメディアタイプ」、RFC3023、2001年1月。
12. Author's Address
12. 作者のアドレス
Keith Moore University of Tennessee Computer Science Department 1122 Volunteer Blvd, Suite 203 Knoxville TN, 37996-3450 USA
テネシーコンピュータサイエンス部の1122ボランティアBlvd、Suite203ノクスビル37996-3450テネシー(米国)のキースムーア大学
EMail: moore@cs.utk.edu
メール: moore@cs.utk.edu
Moore Best Current Practice [Page 13] RFC 3205 HTTP Layering February 2002
2002年2月に層にされるムーア最も良い現在の習慣[13ページ]RFC3205HTTP
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Moore Best Current Practice [Page 14]
ムーアBest現在の習慣[14ページ]
一覧
スポンサーリンク
