« Return to Thread: [RFC] HTTP Information Request
[RFC] HTTP Information Request
by Stefanos Harhalakis-2
::
Rate this Message:
Here is a more formal proposal for the 'Client Information' message I've
sent 3 days before. After examining the 'Timezone Information' feedback I
came to the conclusion that we need something like this.
This draft is not submitted yet since I would like to first send it here. I
hope that you'll be interrested in this and that you'll find it usefull.
Network Working Group S. Harhalakis
Internet-Draft TEI of Thessaloniki
Intended status: Standards Track June 16, 2007
Expires: December 18, 2007
Timezone Information in HTTP
draft-sharhalakis-httpinfo-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 18, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Harhalakis Expires December 18, 2007 [Page 1]
Internet-Draft Timezone Information in HTTP June 2007
Abstract
This document defines a set of information-exchanging HTTP headers as
an optional improvement to HTTP dialogs. Server side application
using those headers will be able to request additional information
from HTTP clients. This way the HTTP protocol is extended to support
optional on-demand additional headers that can be send from clients
when requested.
An extensible communications framework that can be used by future
documents is described. The ABNF description of the corresponding
headers is provided.
Harhalakis Expires December 18, 2007 [Page 2]
Internet-Draft Timezone Information in HTTP June 2007
Discussion
Discussion about this document takes place in http-wg mailing list
(ietf-http-wg@...).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Protocol definition . . . . . . . . . . . . . . . . . . . 6
2.2. Header syntax . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Proxy considerations . . . . . . . . . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
3.1. Client side . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Server side . . . . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Harhalakis Expires December 18, 2007 [Page 3]
Internet-Draft Timezone Information in HTTP June 2007
1. Introduction
1.1. Purpose
Web based application are exploiting the HTTP protocol to achieve
better results and provide additional capabilities. Every now and
then, server side applications introduce additional needs from HTTP
clients. Current HTTP behavior does not provide a basis for clients
to offer additional information upon request (on-demand). The HTTP
protocol could be further extended by providing such a framework.
This document addresses this need by describing a method and a set of
headers to be used in HTTP [RFC2616] so that server side application
may request additional information from clients.
By providing support for on-demand offering of information from
clients, the HTTP protocol will be able to be further extended
without adopting additional headers that will be always exchanged.
This will result in smaller client requests. Apart from that,
willing clients will be able to provide a central management facility
for information that will be send to server-side. Using such a
client, users will be able to have better (centralized) control of
information that will be send to servers and may experience better
server side services that will take advantage of the additionally
provided information.
1.2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements. An implementation that
satisfies all the MUST or REQUIRED level and all the SHOULD level
requirements is said to be "unconditionally compliant"; one that
satisfies all the MUST level requirements but not all the SHOULD
level requirements is said to be "conditionally compliant".
1.3. Terminology
This document uses the following terms:
HTTP client
Every client of the HTTP protocol. Commonly referred to as a web
browser.
Harhalakis Expires December 18, 2007 [Page 4]
Internet-Draft Timezone Information in HTTP June 2007
HTTP header
A HTTP header as described in [RFC2616].
Information element
A title that identifies some information.
Information request
The full list of requested information elements.
The HTTP header specifications of this document are presented in the
augmented Backus-Naur Form that is described in [RFC2616].
Harhalakis Expires December 18, 2007 [Page 5]
Internet-Draft Timezone Information in HTTP June 2007
2. Definition
2.1. Protocol definition
Server side applications MAY use the Information Request (I-RQ)
header to request additional information from HTTP clients. Those
applications MUST NOT assume that clients will respond to their
requests nor that clients support the I-R header.
Client side applications MAY support the server side I-RQ. Those
clients MAY respond to I-RQ with one or more Information Provide
(I-PR) headers. This action will require an additional and almost
identical HTTP request to be sent that will include the additional
headers. Clients that respond to I-RQ MUST inform the server side
application when they are denying one or more I-RQ with an
Information Deny (I-DN) header.
Clients MAY cache per domain/path I-RQ and automatically send I-PR
headers without waiting for an I-RQ. Clients SHOULD update their
cache upon receipt of an I-RQ. This will ensure that they will not
send unneeded data for more than one requests.
2.2. Header syntax
For the purposes of this document, the following HTTP headers are
defined:
information-request = "Information-Request" ":" i-rq i-param
i-rq = i-element *( "," i-element )
i-element = ALPHA *ALNUM ; No LWS
i-param = *( ";" i-param-av )
i-param-av = "Domain" "=" value
/ "Path" "=" value
/ "Secure"
; As in cookies
ALNUM = ALPHA / DIGIT
information-provide = "Information-Provide" ":" i-pr
i-pr = i-pr-one *( "," i-pr-one )
i-pr-one = i-element "=" value
information-deny = "Information-Deny" ":" i-dn
i-dn = i-element *( "," i-element )
Where:
Harhalakis Expires December 18, 2007 [Page 6]
Internet-Draft Timezone Information in HTTP June 2007
value A value as defined in HTTP State Management Mechanism
[RFC2109].
LWS Linear White Space as described in [RFC2616].
Usage of i-param is the same as in cookie-av described in [RFC2109].
Same grammar and semantics apply.
2.3. Proxy considerations
HTTP proxy servers MUST NOT alter this information.
Server side scripts that produce customized results based on the I-PR
information MUST return an appropriate "Vary" header as specified in
paragraph 14.44 of [RFC2616].
Harhalakis Expires December 18, 2007 [Page 7]
Internet-Draft Timezone Information in HTTP June 2007
3. Security Considerations
3.1. Client side
Part or all of the additional provided information may include
personal information. Documents that define the provided information
MUST provide security considerations that characterize the additional
information. HTTP clients MUST NOT provide sensitive information to
servers without letting the user prevent it. Clients MUST either ask
for user permission or provide options for preventing them from
providing the additional information. The latter is RECOMMENDED.
HTTP clients MUST provide secure defaults that protect user privacy.
3.2. Server side
Web based applications MUST treat all this information as user input
that may be invalid. Maliciously formed headers MUST be expected and
addressed as needed.
Harhalakis Expires December 18, 2007 [Page 8]
Internet-Draft Timezone Information in HTTP June 2007
4. IANA Considerations
This specification requires registration of a set of Message Header
Fields for HTTP [RFC3864]:
Header field: Information-Request
Applicable protocol: HTTP
Status: Experimental
Author/change controller:
IETF (iesg@...)
Internet Engineering Task Force
Specification document:
[ this document ]
Header field: Information-Provide
Applicable protocol: HTTP
Status: Experimental
Author/change controller:
IETF (iesg@...)
Internet Engineering Task Force
Specification document:
[ this document ]
Header field: Information-Deny
Applicable protocol: HTTP
Status: Experimental
Author/change controller:
IETF (iesg@...)
Internet Engineering Task Force
Harhalakis Expires December 18, 2007 [Page 9]
Internet-Draft Timezone Information in HTTP June 2007
Specification document:
[ this document ]
Harhalakis Expires December 18, 2007 [Page 10]
Internet-Draft Timezone Information in HTTP June 2007
5. References
5.1. Normative
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] 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.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
5.2. Informative
[I-D.rfc-editor-rfc2223bis]
Reynolds, J. and R. Braden, "Instructions to Request for
Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-08
(work in progress), July 2004.
Harhalakis Expires December 18, 2007 [Page 11]
Internet-Draft Timezone Information in HTTP June 2007
Author's Address
Stefanos Harhalakis
Technological Educational Institute of Thessaloniki
Department of Information Technology
Thessaloniki, Greece
GR
Email: v13@..., v13@...
Harhalakis Expires December 18, 2007 [Page 12]
Internet-Draft Timezone Information in HTTP June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@....
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Harhalakis Expires December 18, 2007 [Page 13]
sent 3 days before. After examining the 'Timezone Information' feedback I
came to the conclusion that we need something like this.
This draft is not submitted yet since I would like to first send it here. I
hope that you'll be interrested in this and that you'll find it usefull.
Network Working Group S. Harhalakis
Internet-Draft TEI of Thessaloniki
Intended status: Standards Track June 16, 2007
Expires: December 18, 2007
Timezone Information in HTTP
draft-sharhalakis-httpinfo-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 18, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Harhalakis Expires December 18, 2007 [Page 1]
Internet-Draft Timezone Information in HTTP June 2007
Abstract
This document defines a set of information-exchanging HTTP headers as
an optional improvement to HTTP dialogs. Server side application
using those headers will be able to request additional information
from HTTP clients. This way the HTTP protocol is extended to support
optional on-demand additional headers that can be send from clients
when requested.
An extensible communications framework that can be used by future
documents is described. The ABNF description of the corresponding
headers is provided.
Harhalakis Expires December 18, 2007 [Page 2]
Internet-Draft Timezone Information in HTTP June 2007
Discussion
Discussion about this document takes place in http-wg mailing list
(ietf-http-wg@...).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Protocol definition . . . . . . . . . . . . . . . . . . . 6
2.2. Header syntax . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Proxy considerations . . . . . . . . . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
3.1. Client side . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Server side . . . . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Harhalakis Expires December 18, 2007 [Page 3]
Internet-Draft Timezone Information in HTTP June 2007
1. Introduction
1.1. Purpose
Web based application are exploiting the HTTP protocol to achieve
better results and provide additional capabilities. Every now and
then, server side applications introduce additional needs from HTTP
clients. Current HTTP behavior does not provide a basis for clients
to offer additional information upon request (on-demand). The HTTP
protocol could be further extended by providing such a framework.
This document addresses this need by describing a method and a set of
headers to be used in HTTP [RFC2616] so that server side application
may request additional information from clients.
By providing support for on-demand offering of information from
clients, the HTTP protocol will be able to be further extended
without adopting additional headers that will be always exchanged.
This will result in smaller client requests. Apart from that,
willing clients will be able to provide a central management facility
for information that will be send to server-side. Using such a
client, users will be able to have better (centralized) control of
information that will be send to servers and may experience better
server side services that will take advantage of the additionally
provided information.
1.2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements. An implementation that
satisfies all the MUST or REQUIRED level and all the SHOULD level
requirements is said to be "unconditionally compliant"; one that
satisfies all the MUST level requirements but not all the SHOULD
level requirements is said to be "conditionally compliant".
1.3. Terminology
This document uses the following terms:
HTTP client
Every client of the HTTP protocol. Commonly referred to as a web
browser.
Harhalakis Expires December 18, 2007 [Page 4]
Internet-Draft Timezone Information in HTTP June 2007
HTTP header
A HTTP header as described in [RFC2616].
Information element
A title that identifies some information.
Information request
The full list of requested information elements.
The HTTP header specifications of this document are presented in the
augmented Backus-Naur Form that is described in [RFC2616].
Harhalakis Expires December 18, 2007 [Page 5]
Internet-Draft Timezone Information in HTTP June 2007
2. Definition
2.1. Protocol definition
Server side applications MAY use the Information Request (I-RQ)
header to request additional information from HTTP clients. Those
applications MUST NOT assume that clients will respond to their
requests nor that clients support the I-R header.
Client side applications MAY support the server side I-RQ. Those
clients MAY respond to I-RQ with one or more Information Provide
(I-PR) headers. This action will require an additional and almost
identical HTTP request to be sent that will include the additional
headers. Clients that respond to I-RQ MUST inform the server side
application when they are denying one or more I-RQ with an
Information Deny (I-DN) header.
Clients MAY cache per domain/path I-RQ and automatically send I-PR
headers without waiting for an I-RQ. Clients SHOULD update their
cache upon receipt of an I-RQ. This will ensure that they will not
send unneeded data for more than one requests.
2.2. Header syntax
For the purposes of this document, the following HTTP headers are
defined:
information-request = "Information-Request" ":" i-rq i-param
i-rq = i-element *( "," i-element )
i-element = ALPHA *ALNUM ; No LWS
i-param = *( ";" i-param-av )
i-param-av = "Domain" "=" value
/ "Path" "=" value
/ "Secure"
; As in cookies
ALNUM = ALPHA / DIGIT
information-provide = "Information-Provide" ":" i-pr
i-pr = i-pr-one *( "," i-pr-one )
i-pr-one = i-element "=" value
information-deny = "Information-Deny" ":" i-dn
i-dn = i-element *( "," i-element )
Where:
Harhalakis Expires December 18, 2007 [Page 6]
Internet-Draft Timezone Information in HTTP June 2007
value A value as defined in HTTP State Management Mechanism
[RFC2109].
LWS Linear White Space as described in [RFC2616].
Usage of i-param is the same as in cookie-av described in [RFC2109].
Same grammar and semantics apply.
2.3. Proxy considerations
HTTP proxy servers MUST NOT alter this information.
Server side scripts that produce customized results based on the I-PR
information MUST return an appropriate "Vary" header as specified in
paragraph 14.44 of [RFC2616].
Harhalakis Expires December 18, 2007 [Page 7]
Internet-Draft Timezone Information in HTTP June 2007
3. Security Considerations
3.1. Client side
Part or all of the additional provided information may include
personal information. Documents that define the provided information
MUST provide security considerations that characterize the additional
information. HTTP clients MUST NOT provide sensitive information to
servers without letting the user prevent it. Clients MUST either ask
for user permission or provide options for preventing them from
providing the additional information. The latter is RECOMMENDED.
HTTP clients MUST provide secure defaults that protect user privacy.
3.2. Server side
Web based applications MUST treat all this information as user input
that may be invalid. Maliciously formed headers MUST be expected and
addressed as needed.
Harhalakis Expires December 18, 2007 [Page 8]
Internet-Draft Timezone Information in HTTP June 2007
4. IANA Considerations
This specification requires registration of a set of Message Header
Fields for HTTP [RFC3864]:
Header field: Information-Request
Applicable protocol: HTTP
Status: Experimental
Author/change controller:
IETF (iesg@...)
Internet Engineering Task Force
Specification document:
[ this document ]
Header field: Information-Provide
Applicable protocol: HTTP
Status: Experimental
Author/change controller:
IETF (iesg@...)
Internet Engineering Task Force
Specification document:
[ this document ]
Header field: Information-Deny
Applicable protocol: HTTP
Status: Experimental
Author/change controller:
IETF (iesg@...)
Internet Engineering Task Force
Harhalakis Expires December 18, 2007 [Page 9]
Internet-Draft Timezone Information in HTTP June 2007
Specification document:
[ this document ]
Harhalakis Expires December 18, 2007 [Page 10]
Internet-Draft Timezone Information in HTTP June 2007
5. References
5.1. Normative
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] 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.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004.
5.2. Informative
[I-D.rfc-editor-rfc2223bis]
Reynolds, J. and R. Braden, "Instructions to Request for
Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-08
(work in progress), July 2004.
Harhalakis Expires December 18, 2007 [Page 11]
Internet-Draft Timezone Information in HTTP June 2007
Author's Address
Stefanos Harhalakis
Technological Educational Institute of Thessaloniki
Department of Information Technology
Thessaloniki, Greece
GR
Email: v13@..., v13@...
Harhalakis Expires December 18, 2007 [Page 12]
Internet-Draft Timezone Information in HTTP June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@....
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Harhalakis Expires December 18, 2007 [Page 13]
« Return to Thread: [RFC] HTTP Information Request
| Free embeddable forum powered by Nabble | Forum Help |
