2004/id/draft-holtman-http-wildcards-00.txt


HTTP Working Group                                     Koen Holtman, TUE
Internet-Draft
Expires: September 18, 1997                               March 18, 1997


                   Wildcards in the Accept-Charset Header

                    draft-holtman-http-wildcards-00.txt


STATUS OF THIS MEMO

        This document is an Internet-Draft. 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".

        To learn the current status of any Internet-Draft, please
        check the "1id-abstracts.txt" listing contained in the
        Internet-Drafts Shadow Directories on ftp.is.co.za
        (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
        Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
        West Coast).

        Distribution of this document is unlimited.  Please send
        comments to the HTTP working group at
        <http-wg@cuckoo.hpl.hp.com>.  Discussions of the working
        group are archived at
        <URL:http://www.ics.uci.edu/pub/ietf/http/>.  General
        discussions about HTTP and the applications which use HTTP
        should take place on the <www-talk@w3.org> mailing list.

ABSTRACT

   The HTTP/1.1 specification (RFC 2068) defines an Accept-Charset
   header, but fails to define a wildcard "*" which could be used in
   this header to match all character sets.  This proposal corrects
   this omission.


1  Introduction

 The HTTP/1.1 specification (RFC 2068) defines an Accept-Charset
 header, but fails to define a wildcard "*" which could be used in
 this header to match all character sets.  This proposal corrects this
 omission.

 A wildcard in the Accept-Charset header is considered important,
 because it allows a better specification of the acceptance of many
 character sets if it is used in combination with q values.  The
 support for many different character sets is one possible route (or
 transition path) for web internationalization.  The existence of this
 path, and the desirability of enabling it, was not properly
 recognized when he HTTP/1.1 specification [1] was written.

 A wildcard can only be used to give an inaccurate specification of
 the support levels for many character sets under HTTP/1.x-based
 server-driven negotiation [1], and this inaccuracy may lead to
 problems.  When used in HTTP transparent content negotiation [2]
 however, the wildcard does not cause inaccurate end results, and in
 fact can be used as a bandwidth-saving device (see section 4.2.1 of
 [3]).


2 Proposed edits

 It is proposed to change the following text in section 14.2 of [1]:

   The ISO-
   8859-1 character set can be assumed to be acceptable to all user
   agents.

          Accept-Charset = "Accept-Charset" ":"
                    1#( charset [ ";" "q" "=" qvalue ] )

   Character set values are described in section 3.4. Each charset may
   be given an associated quality value which represents the user's
   preference for that charset. The default value is q=1. An example is

          Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

   If no Accept-Charset header is present, the default is that any
   character set is acceptable.

 to the text below:

   The ISO-
   8859-1 character set can be assumed to be acceptable to all user
   agents.

          Accept-Charset = "Accept-Charset" ":"
 |                  1#( ( charset | "*" ) [ ";" "q" "=" qvalue ] )

   Character set values are described in section 3.4. Each charset may
   be given an associated quality value which represents the user's
   preference for that charset. The default value is q=1. An example is

          Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

 | The special value "*", if present in the Accept-Charset field,
 | matches every character set (including ISO-8859-1) which is not
 | mentioned elsewhere in the Accept-Charset field.  If no "*" is
 | present in an Accept-Charset field, then all character sets not
 | explicitly mentioned get a quality value of 0, except for
 | ISO-8859-1, which gets a quality value of 1 if not explicitly
 | mentioned. 
   If no Accept-Charset header is present, the default is that any character
   set is acceptable.


3 Compatibility considerations

 The syntax rules in the current version of the HTTP/1.1 specification
 [1] allow a charset value of "*" to be present in the Accept-Charset
 header.  Thus, servers which implement [1] will have no trouble
 parsing a header like

      Accept-Charset: iso-8859-5;q=0.8, *;q=0.2

 According to [1], the "*" value should be interpreted as an unknown
 (unregistered) character set designator.  Thus, servers which
 implement [1] will simply ignore the wildcard if present.


4 Security considerations

 This proposal adds no new HTTP security considerations.


5 References

   [1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and
       T. Berners-Lee.  Hypertext Transfer Protocol -- HTTP/1.1.  RFC
       2068, HTTP Working Group, January, 1997.

   [2] K. Holtman, A. Mutz.  Transparent Content Negotiation in HTTP.
       Internet-Draft draft-ietf-http-negotiation-01.txt, HTTP Working
       Group.

   [3] K. Holtman, A. Mutz.  HTTP Remote Variant Selection Algorithm
       -- RVSA/1.0.  Internet-Draft draft-ietf-http-rvsa-v10-00.txt,
       HTTP Working Group.


6 Author's address

   Koen Holtman
   Technische Universiteit Eindhoven
   Postbus 513
   Kamer HG 6.57
   5600 MB Eindhoven (The Netherlands)
   Email: koen@win.tue.nl


Expires: September 18, 1997

1
2	HTTP Working Group Koen Holtman, TUE
3	Internet-Draft
4	Expires: September 18, 1997 March 18, 1997
5
6
7	Wildcards in the Accept-Charset Header
8
9	draft-holtman-http-wildcards-00.txt
10
11
12	STATUS OF THIS MEMO
13
14	This document is an Internet-Draft. Internet-Drafts are
15	working documents of the Internet Engineering Task Force
16	(IETF), its areas, and its working groups. Note that other
17	groups may also distribute working documents as
18	Internet-Drafts.
19
20	Internet-Drafts are draft documents valid for a maximum of
21	six months and may be updated, replaced, or obsoleted by
22	other documents at any time. It is inappropriate to use
23	Internet-Drafts as reference material or to cite them other
24	than as "work in progress".
25
26	To learn the current status of any Internet-Draft, please
27	check the "1id-abstracts.txt" listing contained in the
28	Internet-Drafts Shadow Directories on ftp.is.co.za
29	(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
30	Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
31	West Coast).
32
33	Distribution of this document is unlimited. Please send
34	comments to the HTTP working group at
35	<http-wg@cuckoo.hpl.hp.com>. Discussions of the working
36	group are archived at
37	<URL:http://www.ics.uci.edu/pub/ietf/http/>. General
38	discussions about HTTP and the applications which use HTTP
39	should take place on the <www-talk@w3.org> mailing list.
40
41	ABSTRACT
42
43	The HTTP/1.1 specification (RFC 2068) defines an Accept-Charset
44	header, but fails to define a wildcard "*" which could be used in
45	this header to match all character sets. This proposal corrects
46	this omission.
47
48
49	1 Introduction
50
51	The HTTP/1.1 specification (RFC 2068) defines an Accept-Charset
52	header, but fails to define a wildcard "*" which could be used in
53	this header to match all character sets. This proposal corrects this
54	omission.
55
56	A wildcard in the Accept-Charset header is considered important,
57	because it allows a better specification of the acceptance of many
58	character sets if it is used in combination with q values. The
59	support for many different character sets is one possible route (or
60	transition path) for web internationalization. The existence of this
61	path, and the desirability of enabling it, was not properly
62	recognized when he HTTP/1.1 specification [1] was written.
63
64	A wildcard can only be used to give an inaccurate specification of
65	the support levels for many character sets under HTTP/1.x-based
66	server-driven negotiation [1], and this inaccuracy may lead to
67	problems. When used in HTTP transparent content negotiation [2]
68	however, the wildcard does not cause inaccurate end results, and in
69	fact can be used as a bandwidth-saving device (see section 4.2.1 of
70	[3]).
71
72
73	2 Proposed edits
74
75	It is proposed to change the following text in section 14.2 of [1]:
76
77	The ISO-
78	8859-1 character set can be assumed to be acceptable to all user
79	agents.
80
81	Accept-Charset = "Accept-Charset" ":"
82	1#( charset [ ";" "q" "=" qvalue ] )
83
84	Character set values are described in section 3.4. Each charset may
85	be given an associated quality value which represents the user's
86	preference for that charset. The default value is q=1. An example is
87
88	Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
89
90	If no Accept-Charset header is present, the default is that any
91	character set is acceptable.
92
93	to the text below:
94
95	The ISO-
96	8859-1 character set can be assumed to be acceptable to all user
97	agents.
98
99	Accept-Charset = "Accept-Charset" ":"
100	\| 1#( ( charset \| "*" ) [ ";" "q" "=" qvalue ] )
101
102	Character set values are described in section 3.4. Each charset may
103	be given an associated quality value which represents the user's
104	preference for that charset. The default value is q=1. An example is
105
106	Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
107
108	\| The special value "*", if present in the Accept-Charset field,
109	\| matches every character set (including ISO-8859-1) which is not
110	\| mentioned elsewhere in the Accept-Charset field. If no "*" is
111	\| present in an Accept-Charset field, then all character sets not
112	\| explicitly mentioned get a quality value of 0, except for
113	\| ISO-8859-1, which gets a quality value of 1 if not explicitly
114	\| mentioned.
115	If no Accept-Charset header is present, the default is that any character
116	set is acceptable.
117
118
119	3 Compatibility considerations
120
121	The syntax rules in the current version of the HTTP/1.1 specification
122	[1] allow a charset value of "*" to be present in the Accept-Charset
123	header. Thus, servers which implement [1] will have no trouble
124	parsing a header like
125
126	Accept-Charset: iso-8859-5;q=0.8, *;q=0.2
127
128	According to [1], the "*" value should be interpreted as an unknown
129	(unregistered) character set designator. Thus, servers which
130	implement [1] will simply ignore the wildcard if present.
131
132
133	4 Security considerations
134
135	This proposal adds no new HTTP security considerations.
136
137
138	5 References
139
140	[1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and
141	T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC
142	2068, HTTP Working Group, January, 1997.
143
144	[2] K. Holtman, A. Mutz. Transparent Content Negotiation in HTTP.
145	Internet-Draft draft-ietf-http-negotiation-01.txt, HTTP Working
146	Group.
147
148	[3] K. Holtman, A. Mutz. HTTP Remote Variant Selection Algorithm
149	-- RVSA/1.0. Internet-Draft draft-ietf-http-rvsa-v10-00.txt,
150	HTTP Working Group.
151
152
153	6 Author's address
154
155	Koen Holtman
156	Technische Universiteit Eindhoven
157	Postbus 513
158	Kamer HG 6.57
159	5600 MB Eindhoven (The Netherlands)
160	Email: koen@win.tue.nl
161
162
163	Expires: September 18, 1997
164