From ahmedat@gmail.com Wed Jan 05 20:51:14 2005 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CmI7e-0005aj-Cm for ietf-http-wg@listhub.w3.org; Wed, 05 Jan 2005 20:51:14 +0000 Received: from wproxy.gmail.com ([64.233.184.195]) by lisa.w3.org with esmtp (Exim 4.34) id 1CmI7V-0004g5-7X for ietf-http-wg@w3.org; Wed, 05 Jan 2005 20:51:05 +0000 Received: by wproxy.gmail.com with SMTP id 55so143560wri for ; Wed, 05 Jan 2005 12:50:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:from:to:subject:date:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=r/lwoi/6lAM9R1Nl1KjnimRjGhe7fldv7EWMHMK1YY6/THdQYmqZmj9Wc7Dr0QqZ5ytKHQZqSFLCp+hJkTbS8mz5ptvKmXW/qXI0wMNxtOmRSicBwNDhFue/MrVM8CWiTTFuu8+5FpjDgp8NJky+xUbAaz9erJexDIve4yWfpck= Received: by 10.54.56.80 with SMTP id e80mr96218wra; Wed, 05 Jan 2005 12:50:43 -0800 (PST) Received: from aaaa ([203.130.21.105]) by smtp.gmail.com with ESMTP id 35sm169140wra.2005.01.05.12.50.36; Wed, 05 Jan 2005 12:50:42 -0800 (PST) Message-ID: <000a01c4f3d5$6b779840$691582cb@aaaa> From: "Alisha Smith" To: Date: Thu, 6 Jan 2005 01:52:12 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C4F392.572C1CA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Received-SPF: pass (lisa.w3.org: domain of ahmedat@gmail.com designates 64.233.184.195 as permitted sender) X-Original-To: ietf-http-wg@w3.org X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on frink.w3.org X-Spam-Level: ** X-Spam-Status: No, hits=2.6 required=6.0 tests=BAYES_30,DATE_IN_FUTURE_12_24, HTML_60_70,HTML_MESSAGE autolearn=no version=2.64 Subject: test X-Archived-At: http://www.w3.org/mid/000a01c4f3d5$6b779840$691582cb@aaaa This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C4F392.572C1CA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable this is testing soory for disterbing http://www.lesjoy.com=20 ------=_NextPart_000_0007_01C4F392.572C1CA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
this is testing soory for = disterbing
http://www.lesjoy.com=20
------=_NextPart_000_0007_01C4F392.572C1CA0-- From julian.reschke@gmx.de Fri Jan 21 10:58:30 2005 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CrwUo-0002mV-Ji for ietf-http-wg@listhub.w3.org; Fri, 21 Jan 2005 10:58:30 +0000 Received: from imap.gmx.net ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1CrwUo-00085P-5Z for ietf-http-wg@w3.org; Fri, 21 Jan 2005 10:58:30 +0000 Received: (qmail invoked by alias); 21 Jan 2005 10:57:58 -0000 Received: from p50825326.dip0.t-ipconnect.de (EHLO [192.168.1.18]) (80.130.83.38) by mail.gmx.net (mp017) with SMTP; 21 Jan 2005 11:57:58 +0100 X-Authenticated: #1915285 Message-ID: <41F0E034.3080605@gmx.de> Date: Fri, 21 Jan 2005 11:57:56 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-http-wg@w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: ietf-http-wg@w3.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on frink.w3.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=BAYES_00 autolearn=ham version=3.0.2 Subject: Defining extensions for the "Expect" header X-Archived-At: http://www.w3.org/mid/41F0E034.3080605@gmx.de Hi, RFC2616, section 3.20 () defines the "Expect" header with extensibility in mind, but doesn't mention any registration process. Is this an oversight? Who can legitimately define new extensions (did this happen so far?)? I'd assume that an IETF standards track document can do this (in the same way as it already occurs for method names and request/response headers). Best regards, Julian From Jeff.Mogul@hp.com Fri Jan 21 19:38:19 2005 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1Cs4br-0004pl-GS for ietf-http-wg@listhub.w3.org; Fri, 21 Jan 2005 19:38:19 +0000 Received: from palrel10.hp.com ([156.153.255.245]) by lisa.w3.org with esmtp (Exim 4.34) id 1Cs4bh-00056x-Aa for ietf-http-wg@w3.org; Fri, 21 Jan 2005 19:38:09 +0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by palrel10.hp.com (Postfix) with ESMTP id 9307F199E; Fri, 21 Jan 2005 11:38:17 -0800 (PST) Received: from wera.hpl.hp.com (wera.hpl.hp.com [15.9.120.80]) by hplms2.hpl.hp.com (8.13.1/8.13.1/HPL-PA Hub) with ESMTP id j0LJcCQH005859; Fri, 21 Jan 2005 11:38:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by wera.hpl.hp.com (8.12.10/8.12.9) with SMTP id j0LJcBmo001217; Fri, 21 Jan 2005 11:38:11 -0800 (PST) From: Jeffrey Mogul Message-Id: <200501211938.j0LJcBmo001217@wera.hpl.hp.com> X-Authentication-Warning: wera.hpl.hp.com: localhost [127.0.0.1] didn't use HELO protocol To: Julian Reschke Cc: ietf-http-wg@w3.org In-reply-to: Your message of "Fri, 21 Jan 2005 11:57:56 +0100." <41F0E034.3080605@gmx.de> X-Organization: Hewlett-Packard Labs, Large Scale Systems group Date: Fri, 21 Jan 2005 11:38:11 -0800 X-Mts: smtp Received-SPF: none (lisa.w3.org: domain of Jeff.Mogul@hp.com does not designate permitted sender hosts) X-Original-To: ietf-http-wg@w3.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on frink.w3.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=7.0 tests=BAYES_00 autolearn=ham version=3.0.2 Subject: Re: Defining extensions for the "Expect" header X-Archived-At: http://www.w3.org/mid/200501211938.j0LJcBmo001217@wera.hpl.hp.com RFC2616, section 3.20 () defines the "Expect" header with extensibility in mind, but doesn't mention any registration process. Is this an oversight? Who can legitimately define new extensions (did this happen so far?)? I'd assume that an IETF standards track document can do this (in the same way as it already occurs for method names and request/response headers). I believe it was an oversight. It certainly wasn't the only such oversight, as evidenced by subsequent efforts that were required to create IANA registries for HTTP status codes (RFC2817) and message headers (RFC 3864). It certainly would be nice if someone could write up an Internet-Draft for an "HTTP expectation code registration procedure". >From our experience with RFC3864, I can't say that this will be a simple process; the IESG is not currently noted for its speed at blessing things. Note that RFC2817, which defined the status code registry, was titled "Upgrading to TLS Within HTTP/1.1". I think it is generally a mistake to define a generic registry within the specification of a specific protocol ... maybe someone thought it would be easier to get one RFC blessed than two, but if the IESG doesn't like the specific protocol, then the registry definition could be held hostage until they are happy about the protocol. Also, it's hard to remember which RFC defined the registry if it's hidden under an unrelated title. Case in point: the IANA listing of Protocol Parameters: http://www.iana.org/numbers.html#H currently says that the HTTP Status Code registry is defined by RFC3293 ... which is entirely unrelated! I suspect this mistake would have been harder to make if the title of the RFC were simply "HTTP Status Code registration procedure" :-) (I'll inform IANA of this bug). -Jeff From helge.hess@opengroupware.org Fri Jan 21 21:40:24 2005 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cs6W0-0002ba-N7 for ietf-http-wg@listhub.w3.org; Fri, 21 Jan 2005 21:40:24 +0000 Received: from medusa.mdlink.de ([213.211.192.34] helo=mail.mdlink.net) by bart.w3.org with esmtp (Exim 4.34) id 1Cs6W0-00023D-C5 for ietf-http-wg@w3.org; Fri, 21 Jan 2005 21:40:24 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 9C2C22CDA22 for ; Fri, 21 Jan 2005 22:39:52 +0100 (CET) Received: from [192.168.1.126] (port-ip-213-211-232-195.reverse.mdcc-fun.de [213.211.232.195]) by mail.mdlink.net (Postfix) with ESMTP id 3AE272CD9CE for ; Fri, 21 Jan 2005 22:39:52 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ietf-http-wg@w3.org From: Helge Hess Date: Fri, 21 Jan 2005 22:39:49 +0100 X-Mailer: Apple Mail (2.619) Received-SPF: none (bart.w3.org: domain of helge.hess@opengroupware.org does not designate permitted sender hosts) X-Original-To: ietf-http-wg@w3.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on frink.w3.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=7.0 tests=BAYES_00 autolearn=ham version=3.0.2 Subject: HTTP PUT / 201 / Location X-Archived-At: http://www.w3.org/mid/F9CA494B-6BF4-11D9-A47C-000D93C1A604@opengroupware.org Hi, we are currently looking at the creation of resources via HTTP as part of the CalDAV effort. Julian Reschke recommended to contact this list for clarification and further discussion of the topic since the issue at hand is not really CalDAV specific. What we discuss is how to solve resource creation with servers that enforce maintenance of the resource URLs, eg legacy RDBMS based servers which create primary keys as part of the resource creation and use primary keys as the identifiers to locate the object in the database. Personally I think that this is already well covered by the base HTTP specification which explicitly allows the use of 'location' in 201 Created responses. The client would perform a PUT on some arbitary URL with the "if-none-match: *" header. If no resource lives on the mentioned URL, the server would allow the request and attempt to create the resource while assigning it a new server based identifier. The server would return a 201 Created response with the location header set to the new, server generated location of the resource. Question is, does that conflict with any PUT related requirement? I read the spec like this: a) 9.6 PUT states: ---snip--- If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. ---snap--- 9.6 doesn't say anything else about that, so I assume that 201 is completely valid for PUT, all strings attached. It also says: ---snip--- ... the origin server can create the resource with that URI. ... ---snap--- While I'm not a native speaker, "with that URI" only says that the server "uses" the URI to create the request, not that it will store the new object "at that URI". b) 10.2.2 201 Created: ---snip--- The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field ---snap--- Note that we do not want to use a redirect 3xx response, we just discuss the usage of the location header in combination with a PUT request and a 201 response. So the mentioned 3xx issues in combination with PUTs do not apply. I would welcome any insight whether the proposed use of PUT is considered valid and whether there is a flaw in my idea of HTTP PUT / 201 / location. Thanks a lot, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From julian.reschke@gmx.de Fri Jan 21 22:03:16 2005 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1Cs6s8-0001Ep-P6 for ietf-http-wg@listhub.w3.org; Fri, 21 Jan 2005 22:03:16 +0000 Received: from pop.gmx.de ([213.165.64.20] helo=mail.gmx.net) by bart.w3.org with smtp (Exim 4.34) id 1Cs6s8-0005YF-EM for ietf-http-wg@w3.org; Fri, 21 Jan 2005 22:03:16 +0000 Received: (qmail invoked by alias); 21 Jan 2005 22:02:44 -0000 Received: from p548563BB.dip.t-dialin.net (EHLO [192.168.0.2]) (84.133.99.187) by mail.gmx.net (mp005) with SMTP; 21 Jan 2005 23:02:44 +0100 X-Authenticated: #1915285 Message-ID: <41F17BFB.60709@gmx.de> Date: Fri, 21 Jan 2005 23:02:35 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess CC: ietf-http-wg@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Received-SPF: pass (bart.w3.org: domain of julian.reschke@gmx.de designates 213.165.64.20 as permitted sender) X-Original-To: ietf-http-wg@w3.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on frink.w3.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=7.0 tests=BAYES_00 autolearn=ham version=3.0.2 Subject: Re: HTTP PUT / 201 / Location X-Archived-At: http://www.w3.org/mid/41F17BFB.60709@gmx.de Helge Hess wrote: > > Hi, > > we are currently looking at the creation of resources via HTTP as part > of the CalDAV effort. Julian Reschke recommended to contact this list > for clarification and further discussion of the topic since the issue at > hand is not really CalDAV specific. Right. Also, we've had similar discussions on the Atom mailing list (creating a new feed entry), so this use-case seems to be quite common. > What we discuss is how to solve resource creation with servers that > enforce maintenance of the resource URLs, eg legacy RDBMS based servers > which create primary keys as part of the resource creation and use > primary keys as the identifiers to locate the object in the database. > > Personally I think that this is already well covered by the base HTTP > specification which explicitly allows the use of 'location' in 201 > Created responses. > > The client would perform a PUT on some arbitary URL with the > "if-none-match: *" header. If no resource lives on the mentioned URL, > the server would allow the request and attempt to create the resource > while assigning it a new server based identifier. The server would > return a 201 Created response with the location header set to the new, > server generated location of the resource. > > Question is, does that conflict with any PUT related requirement? > > I read the spec like this: > > a) 9.6 PUT states: > ---snip--- > If a new resource is created, the origin server MUST inform the user > agent via the 201 (Created) response. > ---snap--- > 9.6 doesn't say anything else about that, so I assume that 201 is > completely valid for PUT, all strings attached. It also says: > ---snip--- > ... the origin server can create the resource with that URI. ... > ---snap--- > While I'm not a native speaker, "with that URI" only says that the > server "uses" the URI to create the request, not that it will store the > new object "at that URI". Filling in my concerns... :-). It also *introduces* PUT as: "The PUT method requests that the enclosed entity be stored under the supplied Request-URI." IMHO, a server that doesn't store the entitiy under the supplied Request-URI, but returns a 2xx status code nevertheless, isn't compliant to this description. > b) 10.2.2 201 Created: > ---snip--- > The newly created resource can be referenced by the URI(s) returned in > the entity of the response, with the most specific URI for the resource > given by a Location header field > ---snap--- > > Note that we do not want to use a redirect 3xx response, we just discuss > the usage of the location header in combination with a PUT request and a > 201 response. So the mentioned 3xx issues in combination with PUTs do > not apply. Nobody argues with the definition of the "Location" header. The only question here is whether is appropriate to use it in a 201 as a result of a PUT. > I would welcome any insight whether the proposed use of PUT is > considered valid and whether there is a flaw in my idea of HTTP PUT / > 201 / location. I'd also appreciate feedback about whether this scenario is common enough to warrant a new method such as "PUTNEW" which is the same as "PUT", but has the parent collection as Request-URI and returns the location of the newly created resource in the Location response header. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From Yves.Lafon@sophia.inria.fr Fri Jan 28 08:28:40 2005 Received: from bart.w3.org ([128.30.52.40]) by frink.w3.org with esmtp (Exim 4.34) id 1CuRUe-0008VR-Tj for ietf-http-wg@listhub.w3.org; Fri, 28 Jan 2005 08:28:40 +0000 Received: from sophia.inria.fr ([138.96.64.20]) by bart.w3.org with esmtp (Exim 4.34) id 1CuRUe-0005cz-CN for ietf-http-wg@w3.org; Fri, 28 Jan 2005 08:28:40 +0000 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id j0S8S9TB025374 for ; Fri, 28 Jan 2005 09:28:09 +0100 Received: from tarantula.inria.fr (tarantula.inria.fr [138.96.10.3]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id j0S8RmFp025190 for ; Fri, 28 Jan 2005 09:27:48 +0100 Received: (from ylafon@localhost) by tarantula.inria.fr (8.12.10/8.12.5) id j0S8RmFb019294; Fri, 28 Jan 2005 09:27:48 +0100 (MET) X-Return-Path: X-Received: from sophia.inria.fr (sophia.inria.fr [138.96.64.20]) by tux.inria.fr (8.12.10/8.12.5) with ESMTP id j0RMDmeT010591 for ; Thu, 27 Jan 2005 23:13:48 +0100 X-Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id j0RMDmTB004629 for ; Thu, 27 Jan 2005 23:13:48 +0100 X-Received: from lisa.w3.org (lisa.w3.org [128.30.52.41]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id j0RMDjFq004608 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 27 Jan 2005 23:13:46 +0100 X-Received: from frink.w3.org ([128.30.52.16]) by lisa.w3.org with esmtp (Exim 4.34) id 1CuHtP-0002Gj-Dk for ylafon@w3.org; Thu, 27 Jan 2005 22:13:35 +0000 X-Received: from lists by frink.w3.org with local (Exim 4.34) id 1CuHtZ-0007yr-Cu for ylafon@w3.org; Thu, 27 Jan 2005 22:13:45 +0000 X-From_: normerty@lycos.com Thu Jan 27 22:13:42 2005 X-Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.34) id 1CuHtV-0007uf-Vl for ietf-http-wg@listhub.w3.org; Thu, 27 Jan 2005 22:13:41 +0000 X-Received: from webmail-outgoing.us4.outblaze.com ([205.158.62.67]) by lisa.w3.org with esmtp (Exim 4.34) id 1CuHtL-0002AD-HA for ietf-http-wg@w3.org; Thu, 27 Jan 2005 22:13:31 +0000 X-Received: from wfilter.us4.outblaze.com (wfilter.us4.outblaze.com [205.158.62.180]) by webmail-outgoing.us4.outblaze.com (Postfix) with QMQP id 117361800217 for ; Thu, 27 Jan 2005 22:13:09 +0000 (GMT) X-OB-Received: from unknown (208.36.123.31) by wfilter.us4.outblaze.com; 27 Jan 2005 22:13:06 -0000 X-Received: by ws7-2.us4.outblaze.com (Postfix, from userid 1001) id D4FE6E5BC7; Thu, 27 Jan 2005 22:13:05 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline MIME-Version: 1.0 X-Received: from [213.156.201.86] by ws7-2.us4.outblaze.com with http for normerty@lycos.com; Thu, 27 Jan 2005 17:13:05 -0500 From: "Anderson Njomdret" To: ietf-http-wg@w3.org Old-Date: Thu, 27 Jan 2005 17:13:05 -0500 X-Originating-Ip: 213.156.201.86 X-Originating-Server: ws7-2.us4.outblaze.com Message-Id: <20050127221305.D4FE6E5BC7@ws7-2.us4.outblaze.com> Received-SPF: pass (lisa.w3.org: domain of normerty@lycos.com designates 205.158.62.67 as permitted sender) X-Diagnostic: Not on the accept list X-Envelope-To: ietf-http-wg Date: Thu, 27 Jan 2005 22:13:45 +0000 Received-SPF: pass (lisa.w3.org: domain of listmaster@w3.org designates 128.30.52.16 as permitted sender) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (sophia.inria.fr [138.96.64.20]); Fri, 28 Jan 2005 09:27:49 +0100 (MET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (sophia.inria.fr [138.96.64.20]); Thu, 27 Jan 2005 23:13:46 +0100 (MET) X-Virus-Scanned: by amavisd-new at sophia.inria.fr Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by tux.inria.fr id j0RMDmeT010591 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on tux.inria.fr X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Level: X-Bogosity: No, tests=bogofilter, spamicity=0.403291, version=0.10.3.1 ReSent-Date: Fri, 28 Jan 2005 09:27:43 +0100 (MET) ReSent-From: Yves Lafon ReSent-To: ietf-http-wg@w3.org ReSent-Subject: [Moderator Action] Re: [Simple] Some thoughts on XCAP's resource architecture ReSent-Message-ID: X-Virus-Scanned: by amavisd-new at sophia.inria.fr Received-SPF: none (bart.w3.org: domain of Yves.Lafon@sophia.inria.fr does not designate permitted sender hosts) X-Original-To: ietf-http-wg@w3.org Subject: Re: [Simple] Some thoughts on XCAP's resource architecture X-Archived-At: http://www.w3.org/mid/20050127221305.D4FE6E5BC7@ws7-2.us4.outblaze.com Kawaguti Ginga wrote: > In Sat, Dec 04, 2004 at 10:44:41AM +0100, > Julian Reschke wrote: > >>That may be a bad choice if lots of your data is in characters that need >>multi-byte sequences, in which case UTF-16 may be more efficient. I >>think XCAP should simply stick with what XML requires (which is UTF-8 >>and UTF-16, nothing more). > > > I agree that "hard-assumption of UTF-8 usage" is a bad choice. > UTF-8 is only a DEFAULT encoding for XML standard. ...it is one of two required encoding... > Yes it is recommended to use UTF-8, but there are many other XML documents > based on other encodings (not only UTF-16, but many more). No, it's not in any way "more" recommended than UTF-16. > If XCAP is intended to be very specific protocol only for > some limited XML documents, then "all documents are UTF-8(and/or UTF-16)" > assumption might work, but it's a bad idea for general protocol design. You need to make this assumption for full portability. These are the only encodings a conforming XML parser has to understand. > There are many ways to specify encodings in a XCAP-only-way, > like appending "http://.../...?encoding=utf-8?...", > but they're not HTTP-standard way. Why would you want to do that? Anyway: if you really need to, you can use the Accept-Charset request header. > And something more, URL string size limitation. > "% encoded" UTF-8 string might suffer even more on this restriction. Even more than what? What alternative are you proposing? > Julian's previous mail: > >>>If that argument was in body part(header might also be recepted), >>>this consideration is much less problem, because there are ways to >>>declare encodings, and usual gateways/clients are aware of them. >> >>Don't understand. How are you sending the document selector inside the >>request body for PUT? > > > For generic HTTP PUT, there's no way, as denoted in your comment. > My consideration was to use something like SOAP envelope. > It shouldn't be "PUT" anymore, and it should be used over > some original rule anyway. But then we're not talking about an HTTP *application* anymore, but only about tunneling *through* HTTP. Best regards, Julian -- _______________________________________________ Find what you are looking for with the Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10