draft-ietf-dhc-proxyserver-opt-04.txt   draft-ietf-dhc-proxyserver-opt-05.txt 
Network Working Group Senthil K Balasubramanian
Internet-Draft Intoto Network Working Group
Expires: December 2005 Michael Alexander Internet Draft Senthil K Balasubramanian
Expires: December 2006 Intoto
Michael Alexander
Gustaf Neumann Gustaf Neumann
Wirtschaftsuniversitaet Wien Wirtschaftsuniversitaet Wien
DHCP Option for Proxy Server Configuration DHCP Option for Proxy Server Configuration
draft-ietf-dhc-proxyserver-opt-04.txt draft-ietf-dhc-proxyserver-opt-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 2005. This Internet-Draft will expire on December 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2006).
IPR Statement
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.
Abstract Abstract
This document defines a new Dynamic Host Configuration Protocol This document defines a new Dynamic Host Configuration Protocol
(DHCP) option, which can be used to configure Proxy Servers in DHCP) option, which can be used to configure the TCP/IP host's
TCP/IP for standard protocols like HTTP, FTP, NNTP, SOCKS, SNMP, Proxy Server configuration for standard protocols like HTTP,FTP,
SLL and etc. Proxy Servers provide controlled and efficient access NNTP,SOCKS, Gopher, SLL and etc. Proxy Server provides controlled
to the Internet, include access control mechanisms for different and efficient access to the Internet by access control mechanism
types of user requests and cache frequently accessed information for different types of user requests and caching frequently accessed
(Web pages and possibly files that might have been downloaded information (Web pages and possibly files that might have been
using FTP and other protocols). downloaded using FTP and other protocols).
1. Terminologies Used 1. Terminologies Used
DHCP Client: A DHCP [RFC-2131] client is an Internet host that DHCP Client: A DHCP [RFC-2131] client is an Internet host that
uses DHCP to obtain configuration information such as a uses DHCP to obtain configuration information such as a
network address. network address.
DHCP Server: A DHCP server [RFC-2131] is an Internet host that DHCP Server: A DHCP server [RFC-2131] is an Internet host that
returns configuration parameters to DHCP clients. returns configuration parameters to DHCP clients.
Proxy Server: In an enterprise network that connects to Internet, Proxy Server: In an enterprise network that connects to Internet, a
a proxy server is a server that acts as an intermediary proxy server is a server that acts as an intermediary between a
between a workstation user and the Internet so that the workstation user and the Internet so that the enterprise can
enterprise can ensure security and administrative control. ensure security and administrative control. A Proxy server MAY
A Proxy server MAY provide caching services or be provide caching services or be associated with or part of a
associated with or part of a gateway server that separates gateway server that separates the enterprise network from
the enterprise network from the outside network (usually the outside network (usually the Internet) and a firewall
the Internet) and a firewall that protects the enterprise that protects the enterprise network from outside intrusion.
network from outside intrusion.
RDF:A language (Resource Description Framework [RDF-SYN]) for PAC : PAC stands for Proxy Auto-Configuration. It is a file
describing properties of web resources. that contains information about the proxy servers to be used.
Most of the browsers support Proxy Auto Configuration File
format to specify the proxies to be used.
URI : Uniform Resource Identifier [RFC-3986]. A Uniform
Resource Identifier is a formatted string that serves as an
identifier for a resource, typically on the Internet. The
formatted string comprises a name or address that can be used
to refer to a internet resource. URIs in common practice include
Uniform Resource Locators(URLs). The following are the examples
of URI:
http://www.ietf.org/rfc/rfc1234.txt
ftp://ftp.isi.edu/rfc/rfc124.txt
In addition to identifying a resource, the URI also provides a
means of acting upon or obtaining a representation of the
resource by describing its primary access mechanism. For
example, http://www.ietf.org is a URI that identifies a resource
and implies that the resource is accessible through HTTP
protocol.
2. Introduction 2. Introduction
The Dynamic Host Configuration Protocol [RFC-2131] provides a The Dynamic Host Configuration Protocol [RFC-2131] provides a
framework for passing configuration information to hosts on a TCP/IP framework for passing configuration information to hosts on a
network. This document describes a DHCP configuration option that TCP/IP network. This document describes a DHCP configuration
can be used to inform a DHCP client of the IP addresses and properties option that can be used to inform a DHCP client of the IP
of one or more proxy services that are either available to it or that addresses and properties of one or more proxy services that are
must be used in order to access internet services, for example through either available to it or that must be used in order to access
a coporate firewall. internet services, for example through a coporate firewall.
The following diagram depicts the typical setup of a proxy server The following diagram depicts the typical setup of a proxy server
providing proxy services to clients on a network that is protected providing proxy services to clients on a network that is protected
by a firewall. by a firewall
+---------------------------+ +-----------+ +---------------------------+ +-----------+
| | |Remote HTTP| | | |Remote HTTP|
| | HTTP |Server | | | HTTP |Server |
| +------------+ +-------------+<--->+-----------+ | +------------+ +-------------+<--->+-----------+
| | Clients | |Proxy Server | | | Clients | |Proxy Server |
| | Inside the |<------>| + | FTP +-----------+ | | Inside the |<------>| + | FTP +-----------+
| | Firewall | |Firewall |<--->|Remote FTP | | | Firewall | |Firewall |<--->|Remote FTP |
| +------------+ +-------------+ |Server | | +------------+ +-------------+ |Server |
| | ^ +-----------+ | | ^ +-----------+
skipping to change at page 3, line 19 skipping to change at page 3, line 45
on the outside Internet. on the outside Internet.
A proxy server can increase network security and user productivity A proxy server can increase network security and user productivity
by filtering content and controlling both internal and external by filtering content and controlling both internal and external
access to information. Also, it provides several other access to information. Also, it provides several other
functionalities that are not discussed here. functionalities that are not discussed here.
3. Requirements terminology 3. Requirements terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC 2119]. this document are to be interpreted as described in [RFC 2119].
4. Proxy Server Configuration Option 4. Proxy Server Configuration Option
This document defines a new DHCP Option called the Proxy Server This document defines a new DHCP Option called the Proxy Server
Configuration Option. The format of the Proxy Server configuration Configuration Option. The format of the Proxy Server configuration
option is: option is:
Code Len Proxy Server Configuration Entry Code Len Proxy Server Configuration Field
+-------+------+------+------+------+------+-....-+------+ +------+------+------+------+------+------+--...-+------+
| TBD | N | e1 | e2 | e3 | e4 | | en | | TBD | N | i1 | i2 | i3 | i4 | | iN |
+-------+------+------+------+------+------+-....-+------+ +------+------+------+------+------+------+--...-+------+
Code is TBD and will be assigned by IANA according to [RFC-2939]. Code is TBD and will be assigned by IANA according to [RFC-2939].
The length N gives the total number of octets in the Proxy Server The length N gives the total number of octets in the proxy server
Configuration entries. configuration field.
The Proxy Server Configuration entry normally consists of a
sequence of Protocol Type (p), len (l), flag (f), IP
address and port. But it can also be a sequence of Protocol
Type (p), Len and RDF[RDF-SYN] metadata.
+--+--+--+--+--+--+--+--+--+
|p |l | f |IP address|port |
+--+--+--+--+--+--+--+--+--+
The Protocol(p) is a two octet integer in network byte order,
length (l) and flag (f) are one octet each; each IP
address is four octets, and each port number is a two-octet
integer encoded in network byte order.
The protocol type(p) specifies the type of protocol and MUST be
one of the following assigned numbers.
+-------------------------------+
| protocol | Number |
+-------------------------------+
| HTTP | 80 |
+-------------------------------+
| FTP | 21 |
+-------------------------------+
| NNTP | 119 |
+-------------------------------+
| Gopher | 70 |
+-------------------------------+
| SSL | TBD |
+-------------------------------+
| SOCKS | 1080 |
+-------------------------------+
| WAIS | 210 |
+-------------------------------+
| IMAP | 220 |
+-------------------------------+
| RDF | TBD |
+-------------------------------+
If the protocol type field is RDF[RDF-SYN], then it MUST be
followed by len (length of RDF metadata) and the actual RDF
metadata.
The length field (l) specifies the length of the Proxy Server
Configuration entry. If some new protocol is introduced in the
future, and if some version of a given dhcpclient doesn't support
it, then that particular entry can be ignored. If it exists, the
next following Proxy Server Configuration Entry can be processed.
The flag field (f) is by default 0. Otherwise, it can either
have "-" or "#".
If it is "-", then the entry becomes a destination address for
exclusion from forwarding to the proxy. If it is "#", then the proxy
requires authentication.
In cases where it makes sense to specify more than one proxy server
for a given protocol, these proxy servers MUST be specified as
additional IP addresses and ports within the same entry. The list is
ordered by precedence, with the most preferred proxy server appearing
first in the list, and the least preferred proxy server appearing last
in the list. The DHCP client SHOULD honor this ordering.
More than one Proxy Server Configuration Entries MAY be specified in
the option. In that case, the list is ordered by precedence, with
the most preferred proxy server appearing first in the list, and the
least preferred proxy server appearing last in the list. The DHCP
client SHOULD honor this ordering.
The format of the Proxy Server Configuration using Metadata type is:
p Len RDF Metadata for the Proxy
+-------+------+----------------------------------+
| RDF | N | RDF |
+-------+------+----------------------------------+
The RDF payload is freeform RDF metadata for describing proxy
properties. The length N gives the number of octets in the RDF
metadata field.
The following entry specifies the sample format of the RDF Meta
data field
HTTP proxy:
<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description rdf:about="http://http-proxy.example.com:8080">
<dc:title>License Gate Proxy</dc:title>
<dc:creator>John Doe</dc:creator>
<dc:publisher>example.com IS</dc:publisher>
<dc:subject>Offsite Resource Access Proxy</dc:subject>
<dc:type>Service</dc:subject>
<dc:rights>example.com employees</dc:rights>
<dc:date>2005-07-11</dc:date>
</rdf:Description>
</rdf:RDF>
FTP proxy:
<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description rdf:about="ftp://ftp-proxy.example.com:8080">
<dc:title>License Gate FTP Proxy</dc:title>
<dc:creator>John Doe</dc:creator>
<dc:publisher>example.com IS</dc:publisher>
<dc:subject>Offsite Resource Access Proxy</dc:subject>
<dc:type>Service</dc:subject>
<dc:rights>example.com employees</dc:rights>
<dc:date>2005-07-11</dc:date>
</rdf:Description>
</rdf:RDF>
As such there is no minimum length to specify a proxy using RDF
metadata. But the minimum sensible statement would be a literal
description of the proxy (<dc:title>License Gate Proxy</dc:title>)
giving a total of 418 characters including the overhead.
For example, with a description element of 60 characters, an URI of The Proxy server configuration field consists of SubOpt/Length/Value
80 characters plus a minimum XML/RDF syntax conformation/namespace tuples for each sub-option, encoded in the following manner:
declaration from below the minimum length would be 418 octes.
21 Octets <?xml version="1.0"?> SubOpt Len Sub-option Value
70 Octets <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]> +------+------+------+------+------+------+--...-+------+
64 Octets <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" | 1 | N | s1 | s2 | s3 | s4 | | sN |
45 Octets xmlns:dc="http://purl.org/dc/elements/1.1/"> +------+------+------+------+------+------+--...-+------+
109 Octets <rdf:Description rdf:about="..80 characters..">
81 Octets <dc:title>..60 characters..</dc:title>
18 Octets </rdf:Description>
10 Octets </rdf:RDF>
5. Option Usage SubOpt Len Sub-option Value
+------+------+------+------+------+------+--...-+------+
| 2 | N | i1 | i2 | i3 | i4 | | iN |
+------+------+------+------+------+------+--...-+------+
The Proxy Server Configuration entries SHOULD not repeat the same The length N of the DHCP Proxy Server Information Option shall
type of proxy entries. The port MUST be a valid TCP/UDP port. include all bytes of the sub-option code/length/value tuples. The
If the length of the Proxy Server Configuration Option exceeds the length N of the sub-options shall be the number of octets in only
maximum permissible within a single option (255 octets), then the that sub-option's value field. The sub-option need not appear in
option MUST be represented in the DHCP message as specified sub-option code order. No pad sub-option is defined, and the proxy
in [RFC-3396]. server configuration field shall NOT be terminated with a 255 sub-
option. The initial assignment of DHCP Proxy Server Sub-options is as
follows
The following example shows how an RDF version of proxy server +------------------+------------------------+
configuration entry of 400 octets is represented in the option. |DHCP Proxy Server | Sub Option Description |
|Sub Option Code | |
+------------------+------------------------+
| 1 | PAC URI |
|------------------+------------------------+
| 2 | MD5 Digest of PAC URI |
+------------------+------------------------+
Code Len Proto Len 5. Proxy Server Configuration Sub Options
+-------+------+------+------+------+------+-....-+------+
| TBD | 255 | RDF | 253 | RDF Meta Data.............|
+-------+------+------+------+------+------+-....-+------+
Code Len Proto Len
+-------+------+------+------+------+------+-....-+------+
| TBD | 149 | RDF | 147 | RDF Meta Data.............|
+-------+------+------+------+------+------+-....-+------+
The following example shows how a proxy server configuration entry 5.1 PAC URI Sub Option and MD5 Digest Sub Option of PAC URI
of 400 octets is represented in RDF along with the normal The PAC URI Sub Option specifies an URI in the UTF-8[STD-63] format.
(p|l|f|IP|port) format. The length of the sub-option is actually depends on the scheme used
to specify an URI. However, it MUST be restricted to a maximum of 255
octets. The DHCP Server MAY compute MD5[MD5] digest on the PAC URI
configured and send the value in MD5 Digest Sub Option(Sub Option 2).
The DHCP Client on receiving this sub-option MUST compute MD5 digest
on the URI received in the PAC URI Sub Option and match it with the
digest present in MD5 Digest Sub Option. If the calculated MD5 digest
doesn't match with the received MD5 digest, then the DHCP client MUST
drop this configuration. The PAC URI Sub-Option is as follows:
+---+---+----+-+-+-------------+----+---+---+...-+---+-----+ SubOpt Len PAC URI Sub-Option
|TBD|255|HTTP|7|0|192.168.5.10 |8080|RDF|243| RDF Meta Data| +-----+-----+-----+-----+-----+--...-+------+
+---+---+----+-+-+-------------+----+---+---+...-+---+-----+ | 1 | N | c1 | c2 | c3 | | cN |
+-----+-----+-----+-----+-----+--...-+------+
+-------+------+------+------+------+------+-....-+------+ SubOpt Len MD5 Digest Sub Option
| TBD | 159 | RDF | 157 | RDF Meta Data.............| +-----+-----+-----+-----+-----+--...-+------+
+-------+------+------+------+------+------+-....-+------+ | 2 | N | c1 | c2 | c3 | | cN |
+-----+-----+-----+-----+-----+--...-+------+
A Proxy Server Configuration Entry with more than one RDF type The MD5 sub option is OPTIONAL and DHCP Server MAY send it if it
of MUST not be sent in this option. This is because the RDF Meta calculates MD5 digest on the PAC URI.
Data is generally more than 255 octets and always requires more
than one option of this type as per [RFC-3396]. However, more than one
proxy server configuration (FTP, HTTP, SOCKS) can be specified with
the same RDF Meta Data as follows:
HTTP and FTP Proxy 6. Option Usage
<?xml version="1.0"?> The DHCP Proxy server configuration option MUST always carry PAC URI
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]> Sub Option. However MD5 Digest of PAC URI Sub Option is OPTIONAL.
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" This is provided for additional security. If the length of the Proxy
xmlns:dc="http://purl.org/dc/elements/1.1/"> server configuration option exceeds the maximum permissible within a
<rdf:Description rdf:about="http://http-proxy.example.com:8080"> single option (255 octets), then the Configuration Option MUST be
<dc:title>License Gate Proxy</dc:title> represented in the DHCP message as specified in [RFC-3396].
<dc:creator>John Doe</dc:creator>
<dc:publisher>example.com IS</dc:publisher>
<dc:subject>Offsite Resource Access Proxy</dc:subject>
<dc:type>Service</dc:subject>
<dc:rights>example.com employees</dc:rights>
<dc:date>2005-07-11</dc:date>
</rdf:Description>
<rdf:Description rdf:about="ftp://ftp-proxy.example.com:8080">
<dc:title>License Gate FTP Proxy</dc:title>
<dc:creator>John Doe</dc:creator>
<dc:publisher>example.com IS</dc:publisher>
<dc:subject>Offsite Resource Access Proxy</dc:subject>
<dc:type>Service</dc:subject>
<dc:rights>example.com employees</dc:rights>
<dc:date>2005-07-11</dc:date>
</rdf:Description>
</rdf:RDF>
6. Security Considerations 7. Security Considerations
The DHCP Options defined here allow an intruder DHCP server to The DHCP Options defined here allow an intruder DHCP server to
misdirect a client, causing it to access a nonexistent or malicious misdirect a client, causing it to access a nonexistent or
proxy server. This allows for a denial of service or man-in-the-middle malicious proxy server. This allows for a denial of service or
attacks. The latter security consideration is a well known property of man-in-the-middle attacks. The latter security consideration is
the DCHP protocol; this option does not create any additional risk a well known property of the DCHP protocol; this option does not
of such attacks. create any additional risk of such attacks.
DHCP provides an authentication mechanism, as described in [RFC-3118], DHCP provides an authentication mechanism, as described in
which may be used if authentication is required. [RFC-3118], which may be used if authentication is required.
7. IANA Considerations 8. IANA Considerations
IANA is requested to assign an option code to the Proxy Server IANA is requested to assign an option code to the Proxy Server
Configuration Option and protocol numbers for the SSL and RDF Configuration Option and protocol numbers for the SSL and RDF
protocol. protocol.
8. Acknowledgements
Thanks to the DHC Working Group for their time and input into the
specification. In particular, thanks to (in alphabetical order)
Bernie Volz, Ralph Droms, Robert Elz, and Ted Lemon for their
thorough review.
9. Normative References 9. Normative References
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol",
March 1997. RFC 2131, March 1997.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options", [RFC-3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options",
RFC 3396, November 2002. RFC 3396, November 2002.
[STD63] Yergeau, F., "UTF-8, a transformation format of
ISO 10646", STD 63, RFC 3629, November 2003.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm",
RFC 1321, April 1992.
10. Informative References 10. Informative References
[RFC-3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC-3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC-2939] Droms, R., "Procedures and IANA Guidelines for Definition [RFC-2939] Droms, R., "Procedures and IANA Guidelines for
of New DHCP Options and Message Types", BCP 43, RFC 2939, Definition of New DHCP Options and Message Types", BCP 43,
September 2000. RFC 2939, September 2000.
[RFC-2616] 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.
[RFC-959] Postel, J. and J. Reynolds, "File Transfer Protocol
(FTP)", STD 9, RFC 959, October 1985.
[RFC-1436] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson,
D. Torrey and B. Albert, "The Internet Gopher Protocol
(a distributed document search and retrieval protocol)",
RFC 1436, March 1993.
[RFC-977] Kantor, B and P. Lapsley, "Network News Transfer
Protocol", RFC 977, February 1986.
[RFC-1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol V5", RFC 1928, April 1996.
[SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
Corp., Feb 9, 1995.
[SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Protocol", Netscape Communications Corp., Nov 18, 1996. Resource Identifiers (URI): Generic Syntax", RFC 3986,
January 2005.
[RFC-1625] M. St. Pierre, J. Fullton, K. Gamiel, J. Goldman, B. Kahle, 11. Acknowledgments
J. Kunze, H. Morris, F. Schiettecatte, "WAIS over Z39.50-1988",
RFC 1625, June 1994.
[RDF-SYN] Becket, D. and B. McBride, Ed., "RDF/XML Syntax Specification", Thanks to the DHC Working Group for their time and input into the
W3C REC-rdf-syntax, February 2004, specification. In particular, thanks to (in alphabetical order)
<http://www.w3.org/TR/rdf-syntax-grammar/>. Bernie Volz, Ralph Droms, Robert Elz, Stig Venaas and Ted Lemon
for their thorough review.
Authors' Addresses Author's Addresses
Senthil K Balasubramanian Senthil Kumar Balasubramanian
Intoto Software (I) Pvt Ltd Intoto Software (I) Pvt Ltd.,
Old No 3, New No 5, First Street, New No 5, Old No 3, First Street,
Nandanam Extension, Nandanam Extension,
Chennai, India 600 035 Chennai, India
Phone: +91 44 5211 2783/4/5 Phone: +91 44 5211 2783/4/5
EMail: ksenthil@intoto.com Email: ksenthil@intoto.com
Michael Alexander Michael Alexander
Wirtschaftsuniversitaet Wien Wirtschaftsuniversitaet Wien
Augasse 2-6 Augasse 2-6
A-1090 Vienna, Austria A-1090 Vienna, Austria
Phone: +43 31336 4467 Phone: +43 31336 4467
Email: malexand@wu-wien.ac.at Email: malexand@wu-wien.ac.at
Gustaf Neumann Gustaf Neumann
Wirtschaftsuniversitaet Wien Wirtschaftsuniversitaet Wien
Augasse 2-6 Augasse 2-6
A-1090 Vienna, Austria A-1090 Vienna, Austria
Phone: +43 31336 4671 Phone: +43 31336 4671
Email: neumann@wu-wien.ac.at Email: neumann@wu-wien.ac.at
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
skipping to change at page 10, line 41 skipping to change at page 8, line 9
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 44 change blocks. 
301 lines changed or deleted 155 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/