From discuss-bounces@apps.ietf.org Fri Aug 03 16:26:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH3iz-0005cw-Nx; Fri, 03 Aug 2007 16:26:17 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IH3iy-0005a8-G4 for discuss-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 16:26:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH3iy-0005Zi-6P for discuss@apps.ietf.org; Fri, 03 Aug 2007 16:26:16 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IH3iw-0001Eu-JG for discuss@apps.ietf.org; Fri, 03 Aug 2007 16:26:16 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DE419142204; Fri, 3 Aug 2007 13:26:13 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6t4EwyVmYNc; Fri, 3 Aug 2007 13:26:09 -0700 (PDT) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3A639142203; Fri, 3 Aug 2007 13:26:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <93A5100D-E88C-4A20-BEA9-08A98DEAB765@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-9--440351418 To: Apps Discuss , Lisa Dusseault's Chairs Subject: Lisa's Apps Area Activity for July 2007 From: Lisa Dusseault Date: Fri, 3 Aug 2007 13:26:02 -0700 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-9--440351418 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Report on BoFs attended in Chicago HTTPBis BOF: sufficient interest, though not overwhelming, in issuing a fixit revision to RFC2616, plus possible work on cookies and on HTTP-related security issues. Will be seeking volunteers for editing and proposed WG chairs. VCardDAV BOF: sufficient interest, again not overwhelming, in revising VCard and working on vCardDAV. (Chris is responsible AD for this and BIFF BOF) BIFF BOF -- Notifications from Mail Stores: Good discussion on feasibility of doing filtering according to model proposal; definite interest in solving some unspecified use cases and on working to define those use cases and confirm they're of shared interest. Document Status and Progress Active Documents: my action - draft-saintandre-rfc4622bis: need to do AD evaluation - draft-snell-atompub-bidi: need to do AD evaluation and learn about implementations - draft-snell-atompub-feature: need to do AD evaluation and learn about implementations - draft-saintandre-jabberid: following up on AD evaluation - draft-ietf-sieve-3028bis: IESG Evaluation phase, work with Cullen and doc shepherd on multiple redirect issues - draft-montemurro-gsma-imei-urn: IESG Evaluation phase, working with Cullen on DISCUSS and with authors on Informational status and how many URNs to register Stalled or waiting on other - draft-crispin-collation-unicasemap: Finished IETF Last Call, waiting for revision (Mark) - draft-hartman-webauth-phishing: Finished IETF Last Call, waiting for an IESG Evaluation telecon - draft-ietf-sieve-body: Finished IETF Last Call, waiting for revision (Philip). - draft-ietf-lemonade-rfc2192bis: finished IETF Last Call and subsequent revision, waiting for IESG Eval telecon - draft-ietf-imapext-sort: Still stalled waiting on unicasemap document - draft-crocker-rfc4234bis: Finished IESG Evaluation, waiting for author to resolve LWSP issue raised in IETF Last Call and IESG Evaluation (Dave or Paul) - draft-ietf-widex-requirements: WIDEX closed, this is now an individual submission and soon to be put in stasis. Finished processing - RFC queue mostly - draft-ietf-atompub-protocol: IESG approved, in RFC queue. - draft-nottingham-atompub-feed-history-11.txt : Entered RFC queue ... 13 sponsored or shepherded documents in RFC queue including above two just added. WG quick status WIDEX: Closed. USEFOR: trundling along on USEPRO issues SIEVE: processing several active documents IMAPEXT: Quiescent, waiting on busy authors. ATOMPUB: Basically finished! CALSIFY: Finishing RFC2445bis and doing work on iTIP --Apple-Mail-9--440351418 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

HTTPBis BOF: sufficient interest, though not = overwhelming, in issuing a fixit revision to RFC2616, plus possible work = on cookies and on HTTP-related security issues.=A0 Will be seeking = volunteers for editing and proposed WG chairs.

VCardDAV BOF: sufficient interest, again not = overwhelming, in revising VCard and working on vCardDAV.=A0 (Chris is = responsible AD for this and BIFF BOF)

BIFF BOF -- = Notifications from Mail Stores: Good discussion on feasibility of doing = filtering according to model proposal; definite interest in solving some = unspecified use cases and on working to define those use cases and = confirm they're of shared interest.


Document = Status and Progress

Active Documents: my action
=A0- draft-saintandre-rfc4622bis: need to do = AD evaluation
=A0- draft-snell-atompub-bidi: = need to do AD evaluation and learn about implementations
=A0- draft-snell-atompub-feature: need to do AD = evaluation and learn about implementations
=A0- = draft-saintandre-jabberid: following up on AD evaluation
-=A0draft-ietf-sieve-3028bis:=A0IESG Evaluation = phase,=A0 work with Cullen and doc shepherd on multiple redirect = issues

Stalled or waiting on other
-=A0draft-crispin-collation-unicasemap:=A0Finished = IETF Last Call, waiting for revision (Mark)
=A0- = draft-ietf-lemonade-rfc2192bis:=A0 finished IETF Last Call and = subsequent revision, waiting for IESG Eval telecon
=A0- draft-ietf-imapext-sort:=A0 Still stalled = waiting on unicasemap document=A0
=A0- = draft-crocker-rfc4234bis: Finished IESG Evaluation, waiting for author = to resolve LWSP issue raised in IETF Last Call and IESG Evaluation (Dave = or Paul)
=A0- = draft-ietf-widex-requirements: WIDEX closed, this is now an individual = submission and soon to be put in stasis.=A0
Finished processing - RFC = queue mostly
- draft-ietf-atompub-protocol:=A0 = IESG approved, in RFC queue.
=A0- = draft-nottingham-atompub-feed-history-11.txt=A0:=A0 Entered RFC = queue=A0
=A0... 13 sponsored or = shepherded documents in RFC queue including above two just = added.

WG quick status
WIDEX: = Closed.
USEFOR: trundling along on = USEPRO issues
SIEVE: processing several active = documents
IMAPEXT: Quiescent, waiting on = busy authors.
ATOMPUB: Basically = finished!
CALSIFY: Finishing RFC2445bis = and doing work on iTIP
= --Apple-Mail-9--440351418-- From discuss-bounces@apps.ietf.org Sun Aug 05 13:35:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHk0G-0004GW-Rd; Sun, 05 Aug 2007 13:34:56 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IHk0G-0004GR-0f for discuss-confirm+ok@megatron.ietf.org; Sun, 05 Aug 2007 13:34:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHk0F-0004GJ-NJ for discuss@apps.ietf.org; Sun, 05 Aug 2007 13:34:55 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IHk0E-0006N9-3j for discuss@apps.ietf.org; Sun, 05 Aug 2007 13:34:55 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 50DEE142203 for ; Sun, 5 Aug 2007 10:34:53 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+wCKY8AAqw3 for ; Sun, 5 Aug 2007 10:34:47 -0700 (PDT) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B29591421F7 for ; Sun, 5 Aug 2007 10:34:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) To: Apps Discuss Message-Id: <58A7C880-E6A5-4947-8BF0-DA502D4481B7@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-3--277837194 References: From: Lisa Dusseault Subject: Fwd: Last Call: draft-saintandre-rfc4622bis (Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)) to Proposed Standard Date: Sun, 5 Aug 2007 10:34:36 -0700 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-3--277837194 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI - a fix to allowed characters and their escaping. lisa Begin forwarded message: > From: The IESG > Date: August 4, 2007 12:42:53 PM PDT > To: IETF-Announce > Subject: Last Call: draft-saintandre-rfc4622bis (Internationalized > Resource Identifiers (IRIs) and Uniform Resource Identifiers > (URIs) for the Extensible Messaging and Presence Protocol (XMPP)) > to Proposed Standard > Reply-To: ietf@ietf.org > > The IESG has received a request from an individual submitter to > consider > the following document: > > - 'Internationalized Resource Identifiers (IRIs) and Uniform Resource > Identifiers (URIs) for the Extensible Messaging and Presence > Protocol > (XMPP) ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the > ietf@ietf.org mailing lists by 2007-09-01. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-saintandre-rfc4622bis-01.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi? > command=view_id&dTag=15924&rfc_flag=0 > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-3--277837194 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 FYI - a fix to allowed = characters and their escaping.

lisa

Begin = forwarded message:

From: = The IESG <iesg-secretary@ietf.org>
Date: August 4, 2007 12:42:53 PM = PDT
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Last Call: = draft-saintandre-rfc4622bis (Internationalized=A0 Resource Identifiers (IRIs) = and Uniform Resource Identifiers=A0 = (URIs) for the Extensible Messaging and Presence Protocol=A0 (XMPP)) to Proposed = Standard=A0
Reply-To: = ietf@ietf.org

The = IESG has received a request from an individual submitter to = consider
the following = document:

- 'Internationalized Resource Identifiers (IRIs) and = Uniform Resource=A0
=A0=A0 = Identifiers (URIs) for the Extensible Messaging and Presence = Protocol=A0
=A0=A0 = (XMPP) '
=A0=A0 = <draft-saintandre-rfc4622bis-01.txt> as a Proposed = Standard

The IESG plans to make a decision in the next few = weeks, and solicits
final comments on this = action.=A0 Please send = substantive comments to the
ietf@ietf.org mailing lists by = 2007-09-01. Exceptionally,=A0
comments = may be sent to iesg@ietf.org = instead. In either case, please=A0
retain = the beginning of the Subject line to allow automated sorting.

The file = can be obtained via


IESG = discussion can be tracked via


IETF-Announce mailing list
https://www1= .ietf.org/mailman/listinfo/ietf-announce
=
= --Apple-Mail-3--277837194-- From discuss-bounces@apps.ietf.org Tue Aug 14 06:45:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKtsS-00089U-Hu; Tue, 14 Aug 2007 06:43:56 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IKtsR-00088l-4R for discuss-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 06:43:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKtsQ-00088d-Do for discuss@apps.ietf.org; Tue, 14 Aug 2007 06:43:54 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKtsM-0003ML-3e for discuss@apps.ietf.org; Tue, 14 Aug 2007 06:43:54 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Aug 2007 12:43:46 +0200 X-IronPort-AV: i="4.19,259,1183327200"; d="eml'208?scan'208,208,217"; a="150544342:sNHT2983190078" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7EAhk09005247; Tue, 14 Aug 2007 12:43:46 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp272.cisco.com [10.61.65.16]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7EAhex0012840; Tue, 14 Aug 2007 10:43:40 GMT Message-ID: <46C18755.2080404@cisco.com> Date: Tue, 14 Aug 2007 12:43:33 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: vcarddav@ietf.org, Apps Discuss Subject: [Fwd: Notes from VCardDAV BOF] Content-Type: multipart/mixed; boundary="------------070702060601040507000104" DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=40671; t=1187088226; x=1187952226; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20[Fwd=3A=20Notes=20from=20VCardDAV=20BOF] |Sender:=20; bh=Vg2YOKEM9nIofoGLla9Cz87pOERsguBE7b2IFXlcD/I=; b=W6MSIDXHSZv2UJsY58Ew9IPlDVWlz+sQYsSckDG1cDbC3Ub1LPcbVcZUh/wMVvp8gB7+Xr7f ywGQHiU00Rv0LNoO9FsKOReC3Aeter2OoRP0rDQBXSBUJa8w1+opjZNe; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a5688aefc17a46e833761118aa2b55bf Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This is a multi-part message in MIME format. --------------070702060601040507000104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Attached minutes that Lisa took for the vcarddav BOF at IETF 69. The BoF chairs would like to thank those who participated, and in particular, the presenters. If you attended, could you please take a moment to review Lisa's notes? These will be the basis for the BoF minutes. Regards, Eliot --------------070702060601040507000104 Content-Type: message/rfc822; name="Notes from VCardDAV BOF.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Notes from VCardDAV BOF.eml" X-Account-Key: account2 X-Mozilla-Keys: Received: from xbh-ams-331.emea.cisco.com ([144.254.231.71]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 23:11:58 +0200 Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 23:11:58 +0200 Received: from sj-iport-2.cisco.com ([171.71.176.71]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 14:11:52 -0700 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 26 Jul 2007 14:11:53 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6QLBoEQ014977 for ; Thu, 26 Jul 2007 14:11:50 -0700 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6QLBJU7018963 for ; Thu, 26 Jul 2007 21:11:50 GMT Received: from laweleka.osafoundation.org ([204.152.186.98]) by sj-inbound-b.cisco.com with ESMTP; 26 Jul 2007 14:11:47 -0700 X-from-outside-Cisco: 204.152.186.98 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJypqEbMmLpi/2dsb2JhbACCZQ X-IronPort-AV: i="4.16,584,1175497200"; d="scan'208,217"; a="19044350:sNHT36389352" Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 20BB91421FD; Thu, 26 Jul 2007 14:11:47 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvrczyvutGqn; Thu, 26 Jul 2007 14:11:45 -0700 (PDT) Received: from [130.129.84.230] (unknown [130.129.84.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A257E1421F9; Thu, 26 Jul 2007 14:11:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) To: "Kurt D. Zeilenga" , Eliot Lear , Chris Newman Message-Id: <981EEC06-7147-4A0C-944C-14AFF2CD9678@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-37-1018673851 From: Lisa Dusseault Subject: Notes from VCardDAV BOF Date: Thu, 26 Jul 2007 16:11:43 -0500 X-Mailer: Apple Mail (2.752.3) Authentication-Results: sj-dkim-1; header.From=lisa@osafoundation.org; dkim=neutral Return-Path: lisa@osafoundation.org X-OriginalArrivalTime: 26 Jul 2007 21:11:52.0827 (UTC) FILETIME=[96C5CCB0:01C7CFC9] --Apple-Mail-37-1018673851 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed VCardDAV BoF 1. Cyrus Daboo presented "VCard Issues". Even though VCARD 3.0 has been around for nine years, many mobile devices still use the old 2.1 specification, either alone or with non- IETF extensions. Some of the issues a WG could deal with include a lack of internationalization support, a few issues that have been found to be ambiguous, and a clear extensibility model. Cyrus proposes to do one new document merging RFC2425 and RFC2426 into one, in which extensions become part of the core proposal. A new MIME type could advertise proper UTF/8 support. An XML-based variant of vCard would be good to define -- one in which the semantics are identical and mapping can be automated -- because XML- formatted vCards are already in use at least in XMPP. Announcement: vCard workshop is planned by the CalConnect consortium, September 18th 2007 (see http://www.calconnect.org/ vcardworkshop.shtml ). 2. Cyrus Daboo on CardDAV Generally, an access protocol for vCard could easily follow the model of CalDAV. There's already been some comments leading to somewhat different syntax, but no argument over the basic architecture. Some of the longstanding WebDAV functional alternatives come up here again, like HTTP caching and whether the data of a vcard should be treated as resource content (body) or properties (metadata). Both CalDAV and CardDAV could use better synchronization functionality. One approach is described in draft-daboo-webdav- sync-00, which also covers non-application-specific use cases. A feature that would avoid polling the server to see changes would be good too. Otherwise, CardDAV would actually be simpler than CalDAV because there are fewer complicating issues such as recurrences and timezones. A mailing list has been set up at vcarddav@ietf.org. Comments: - Rohan Mahy pointed out the draft he authored with notification mechanisms for HTTP resources, which could apply to WebDAV collections or CardDAV resources. 3. Alexey Melnikov: LDAP and vCard Could we use LDAP as an access protocol for vCards? It's good for partial retrieval of this kind of information. Many vCard properties map one-to-one to standard LDAP attributes already. On the other hand, vCard allows all kinds of extensibility which LDAP does not. Similarly there are LDAP attributes that can't be represented in vCard. The InetOrgPerson is the closest LDAP object class to a vCard, and this is not a standard (although that could be fixed). Perhaps most importantly on the "con" side of using LDAP for this purpose, write access is not common on LDAP servers. It's a matter of policy often to keep corporate directory information carefully regulated. We assume that we'll need write access so that people can store their address books containing all kinds of arbitrary entries, not just corporate directory entries. People's address books, today commonly stored locally in vCard format and varations, commonly contain not only cards for people and organizations and places well beyond just one organization, but they also contain more than one contact number or address for certain people. LDAP is more tailored to one organization, so it does not provide a natural way of providing both a "work" and a "home" address for an individual. Comments - Cyrus Daboo pointed out that we will need vCard mapping. A system where the LDAP directory is exposed as a read-only address book in CardDAV is quite easy to imagine. Alexey added that there are already email clients that can fetch address books from LDAP although they can't edit those. - Kurt Zeilenga says that LDAP is good for storing blobs, but as soon as you want to do stuf with blobs it's not as good. - Dave Crocker asked a clarification of whether we were proposing of defining a generic vCard/LDAP mapping to support existing use cases, but not turn LDAP into a data model for storing an address book because it would be a crippled mechanism. Asked for clarification of the LDAP writeability issue. - Leif Johansen asked about whether mappings can be completely automated? 4. Discussion of Proposed Charter The charter was posted to the Apps Discuss mailing list. Chris asked that it be reposted to the vcarddav mailing list. Kurt pointed out that we may get participation from people not yet in this room, at the CalConnect workshop and from OMA. Comments: - ??? questioned - Cyrus Daboo points out that there will be OMA people at the CalConnect workshop. - Rohan Mahy: The charter needs to say whether synchronization is in or out of scope. CONSENSUS CALLs: CALL: Is this work that is appropriate for the IETF to undertake? Consensus in favour. CALL: Who in this room will actively contribute to the effort if it becomes an IETF effort? Significant portion of the room was interested in contributing. CALL: Is the LDAP mapping appropriate IETF work? Consensus yes. CALL: Who would contribute? Only a couple hands. CALL: Is developing a vCard access protocol IETF work? Consensus yes CALL: Who would contribute? half dozen hands. Pete Resnick, Alexey Melnikov and Dave Crocker volunteered to edit the vCard base spec. Eliot asked also for volunteers for a chair of the WG to speak to Chris Newman. Chris will be looking for a process chair and a newbie chair. --Apple-Mail-37-1018673851 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
VCardDAV = BoF

1.=A0 Cyrus Daboo presented "VCard Issues". =A0
Even though VCARD 3.0 has been around for = nine years, many mobile devices still use the old 2.1 specification, = either alone or with non-IETF extensions.=A0 = Some of the issues a WG could deal with include a lack of = internationalization support, a few issues that have been found to be = ambiguous, and a clear extensibility model. =A0
Cyrus proposes to do one new document merging = RFC2425 and RFC2426 into one, in which extensions become part of the = core proposal.=A0 A new MIME type = could advertise proper UTF/8 support.=A0 = An XML-based variant of vCard would be good to define -- one in = which the semantics are identical and mapping can be automated -- = because XML-formatted vCards are already in use at least in = XMPP.

Announcement: vCard workshop is planned by the CalConnect = consortium, September 18th 2007 (see http://www.calconnect.org/vcardworkshop.shtml=A0 = ).

2.=A0 Cyrus Daboo on CardDAV
Generally, an access protocol for vCard could = easily follow the model of CalDAV.=A0 = There's already been some comments leading to somewhat different = syntax, but no argument over the basic architecture. Some of the = longstanding WebDAV functional alternatives come up here again, like = HTTP caching and whether the data of a vcard should be treated as = resource content (body) or properties (metadata). =A0
Both CalDAV and CardDAV could use better = synchronization functionality.=A0 = One approach is described in draft-daboo-webdav-sync-00, which = also covers non-application-specific use cases.=A0 = A = feature that would avoid polling the server to see changes would be good = too.=A0 Otherwise, CardDAV would actually be simpler than CalDAV because = there are fewer complicating issues such as recurrences and = timezones.
A mailing list has been set up at = vcarddav@ietf.org.
Comments:
=A0- Rohan Mahy pointed out the draft he authored with notification = mechanisms for HTTP resources, which could apply to WebDAV collections = or CardDAV resources.
3.=A0 = Alexey Melnikov: LDAP and vCard

Could we use LDAP = as an access protocol for vCards?=A0 = It's good for partial retrieval of this kind of = information.=A0 Many vCard properties map one-to-one to standard LDAP attributes = already. =A0
On the other hand, vCard allows all kinds of = extensibility which LDAP does not.=A0 = Similarly there are LDAP attributes that can't be represented in = vCard. The InetOrgPerson is the closest LDAP object class to a vCard, = and this is not a standard (although that could be = fixed).

Perhaps most importantly on the "con" side of using LDAP for this = purpose, write access is not common on LDAP servers.=A0 = It's a matter of policy often to keep corporate directory = information carefully regulated.=A0 = We assume that we'll need write access so that people can store = their address books containing all kinds of arbitrary entries, not just = corporate directory entries.=A0 =A0

People's address = books, today commonly stored locally in vCard format and varations, = commonly contain not only cards for people and organizations and places = well beyond just one organization, but they also contain more than one = contact number or address for certain people.=A0 = LDAP is more tailored to one organization, so it does not provide = a natural way of providing both a "work" and=A0 = a = "home" address for an individual.=A0
Comments
=A0- Cyrus Daboo pointed out that we will need vCard = mapping.=A0 A system where the LDAP directory is exposed as a read-only = address book in CardDAV is quite easy to imagine.=A0 = Alexey added that there are already email clients that can fetch = address books from LDAP although they can't edit = those.
=A0- Kurt Zeilenga says that LDAP is good for storing blobs, but as = soon as you want to do stuf with blobs it's not as = good.
=A0- Dave Crocker asked a clarification of whether we were proposing = of defining a generic vCard/LDAP mapping to support existing use cases, = but not turn LDAP into a data model for storing an address book because = it would be a crippled mechanism.=A0 = Asked for clarification of the LDAP writeability = issue.
=A0- Leif Johansen asked about whether mappings can be completely = automated?
4.=A0 = Discussion of Proposed Charter

The charter was = posted to the Apps Discuss mailing list.=A0 = Chris asked that it be reposted to the vcarddav mailing = list.=A0 Kurt pointed out that we may get participation from people not = yet in this room, at the CalConnect workshop and from OMA. = =A0
Comments:
=A0- ??? questioned=A0
=A0- Cyrus Daboo points out that there will be OMA people at the = CalConnect workshop.
=A0- Rohan Mahy: The charter needs to say whether synchronization is = in or out of scope. =A0

CONSENSUS = CALLs:=A0
CALL: Is this work that is appropriate for = the IETF to undertake?=A0 Consensus in = favour.

CALL: Who in this room will actively contribute to the effort if = it becomes an IETF effort?=A0 Significant = portion of the room was interested in = contributing.
CALL: Is the LDAP mapping appropriate IETF = work? Consensus yes.
CALL: Who would contribute? Only a couple = hands.

CALL: Is developing a vCard access protocol IETF = work?=A0 Consensus yes
CALL: Who would = contribute?=A0 half dozen hands.
Pete Resnick, Alexey Melnikov and Dave = Crocker volunteered to edit the vCard base spec.

Eliot asked also = for volunteers for a chair of the WG to speak to Chris = Newman.=A0 Chris will be looking for a process chair and a newbie = chair.=A0

= --Apple-Mail-37-1018673851-- --------------070702060601040507000104-- From discuss-bounces@apps.ietf.org Sun Aug 19 23:42:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMy7j-0004lG-C0; Sun, 19 Aug 2007 23:40:15 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IMy7h-0004l1-Rs for discuss-confirm+ok@megatron.ietf.org; Sun, 19 Aug 2007 23:40:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMy7h-0004kt-Ht for discuss@apps.ietf.org; Sun, 19 Aug 2007 23:40:13 -0400 Received: from mxout-04.mxes.net ([216.86.168.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IMy7g-0008Na-B6 for discuss@apps.ietf.org; Sun, 19 Aug 2007 23:40:13 -0400 Received: from [192.168.1.102] (unknown [121.44.235.196]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 92016A3228; Sun, 19 Aug 2007 23:40:08 -0400 (EDT) In-Reply-To: <6.0.0.20.2.20070610165356.0a69cec0@localhost> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <6.0.0.20.2.20070610165356.0a69cec0@localhost> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2A7EE350-163E-438E-8A63-85B69C810513@mnot.net> Content-Transfer-Encoding: 7bit From: Mark Nottingham Subject: Re: Straw-man charter for http-bis Date: Mon, 20 Aug 2007 13:39:55 +1000 To: Martin Duerst X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Richard Ishida , Apps Discuss , Felix Sasaki , "ietf-http-wg@w3.org Group" , Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i74 On 10/06/2007, at 6:05 PM, Martin Duerst wrote: > - RFC 2616 prescribes that headers containing non-ASCII have to use > either iso-8859-1 or RFC 2047. This is unnecessarily complex and > not necessarily followed. At the least, new extensions should be > allowed to specify that UTF-8 is used. -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Sun Aug 19 23:42:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMy8L-0005cC-Jb; Sun, 19 Aug 2007 23:40:53 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IMy8K-0005c5-1P for discuss-confirm+ok@megatron.ietf.org; Sun, 19 Aug 2007 23:40:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMy8J-0005bx-O9 for discuss@apps.ietf.org; Sun, 19 Aug 2007 23:40:51 -0400 Received: from mxout-04.mxes.net ([216.86.168.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IMy8J-0008R1-Dk for discuss@apps.ietf.org; Sun, 19 Aug 2007 23:40:51 -0400 Received: from [192.168.1.102] (unknown [121.44.235.196]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id E12DAA321C; Sun, 19 Aug 2007 23:40:48 -0400 (EDT) In-Reply-To: <6.0.0.20.2.20070610165356.0a69cec0@localhost> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <6.0.0.20.2.20070610165356.0a69cec0@localhost> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <088FB13E-F12F-4BE7-94FB-78B21C51512E@mnot.net> Content-Transfer-Encoding: 7bit From: Mark Nottingham Subject: Character encodings in headers [i74][was: Straw-man charter for http-bis] Date: Mon, 20 Aug 2007 13:40:36 +1000 To: Martin Duerst X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Richard Ishida , Apps Discuss , Felix Sasaki , "ietf-http-wg@w3.org Group" , Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 10/06/2007, at 6:05 PM, Martin Duerst wrote: > - RFC 2616 prescribes that headers containing non-ASCII have to use > either iso-8859-1 or RFC 2047. This is unnecessarily complex and > not necessarily followed. At the least, new extensions should be > allowed to specify that UTF-8 is used. My .02; I'm concerned about allowing UTF-8; it may break existing implementations. I'd like to see the text just require that the actual character set be 8859-1, but to allow individual extensions to nominate encodings *like* 2047,without being restricted to it. For example, the encoding specified in 3987 is appropriate for URIs. However, it *has* to be explicit; I've heard some people read this requirement and think that they need to check *every* header for 2047 encoding. So, I think this means; 1) Change "Words of *TEXT MAY contain characters from character sets other than ISO-8859-1 [22] only when encoded according to the rules of RFC 2047 [14]." to "Words of *TEXT MUST NOT contain characters from character sets other than ISO-885901 [22]." and, 2) Identify headers that may have non-8859 content and explicitly say how to encode them (IRI, 2047, whatever; the existing ones will have to be 2047, I believe), modifying their BNF to suit. 3) When we document extensibility, require new headers to nominate any encoding explicitly. -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Mon Aug 20 02:59:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN1Cm-0006oZ-7y; Mon, 20 Aug 2007 02:57:40 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IN1Cl-0006oU-5a for discuss-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 02:57:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN1Ch-0006oI-3F for discuss@apps.ietf.org; Mon, 20 Aug 2007 02:57:35 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN1Cg-00040o-O2 for discuss@apps.ietf.org; Mon, 20 Aug 2007 02:57:35 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 124C71EE379; Mon, 20 Aug 2007 02:57:29 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qxoJxE97zWg; Mon, 20 Aug 2007 02:57:26 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 2CDFF1EE376; Mon, 20 Aug 2007 02:57:03 -0400 (EDT) Message-ID: <46C93B36.7070503@cs.utk.edu> Date: Mon, 20 Aug 2007 02:56:54 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Mark Nottingham Subject: Re: Character encodings in headers [i74][was: Straw-man charter for http-bis] References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <6.0.0.20.2.20070610165356.0a69cec0@localhost> <088FB13E-F12F-4BE7-94FB-78B21C51512E@mnot.net> In-Reply-To: <088FB13E-F12F-4BE7-94FB-78B21C51512E@mnot.net> X-Enigmail-Version: 0.95.2 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Richard Ishida , Apps Discuss , Felix Sasaki , "ietf-http-wg@w3.org Group" , Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Mark Nottingham wrote: > On 10/06/2007, at 6:05 PM, Martin Duerst wrote: >> - RFC 2616 prescribes that headers containing non-ASCII have to use >> either iso-8859-1 or RFC 2047. This is unnecessarily complex and >> not necessarily followed. At the least, new extensions should be >> allowed to specify that UTF-8 is used. > > My .02; > > I'm concerned about allowing UTF-8; it may break existing > implementations. concur. though at least it is possible to distinguish utf-8 from 8859-1. also, I'll note that supporting utf-8 in a way that is backward compatible with existing implementations is almost certainly more complex (and thus more costly, error-prone, etc) than supporting rfc 2047. > > I'd like to see the text just require that the actual character set be > 8859-1, but to allow individual extensions to nominate encodings > *like* 2047,without being restricted to it. For example, the encoding > specified in 3987 is appropriate for URIs. However, it *has* to be > explicit; I've heard some people read this requirement and think that > they need to check *every* header for 2047 encoding. 2047 was specifically not intended for use with protocol elements that have meaning to protocol engines. how many HTTP headers contain text that is intended solely for human use? From discuss-bounces@apps.ietf.org Mon Aug 20 03:24:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN1af-0007mJ-CS; Mon, 20 Aug 2007 03:22:21 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IN1ad-0007iA-PY for discuss-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 03:22:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN1ad-0007i0-Fy for discuss@apps.ietf.org; Mon, 20 Aug 2007 03:22:19 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN1ac-0004ak-2s for discuss@apps.ietf.org; Mon, 20 Aug 2007 03:22:19 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IN1aS-000Iou-8C; Mon, 20 Aug 2007 03:22:08 -0400 Date: Mon, 20 Aug 2007 03:22:06 -0400 From: John C Klensin To: Mark Nottingham , Martin Duerst Subject: Re: Character encodings in headers [i74][was: Straw-man charter for http-bis] Message-ID: <157F4F253535B9C73F8EDC75@p3.JCK.COM> In-Reply-To: <088FB13E-F12F-4BE7-94FB-78B21C51512E@mnot.net> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <6.0.0.20.2.20070610165356.0a69cec0@localhost> <088FB13E-F12F-4BE7-94FB-78B21C51512E@mnot.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Paul Hoffman , Apps Discuss , Felix Sasaki , "ietf-http-wg@w3.org Group" , Richard Ishida X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Monday, 20 August, 2007 13:40 +1000 Mark Nottingham wrote: > On 10/06/2007, at 6:05 PM, Martin Duerst wrote: >> - RFC 2616 prescribes that headers containing non-ASCII have >> to use either iso-8859-1 or RFC 2047. This is unnecessarily >> complex and not necessarily followed. At the least, new >> extensions should be allowed to specify that UTF-8 is used. > > My .02; > > I'm concerned about allowing UTF-8; it may break existing > implementations. And whatever is done about it should be consistent with the EAI work. Otherwise, we are likely to find ourselves in big trouble going down the line. > I'd like to see the text just require that the actual > character set be 8859-1, but to allow individual extensions to > nominate encodings *like* 2047,without being restricted to it. > For example, the encoding specified in 3987 is appropriate for > URIs. However, it *has* to be explicit; I've heard some people > read this requirement and think that they need to check > *every* header for 2047 encoding. Sigh. My own sense is that, going forward, we need to lose 8859-N, not make it the default (or only) character set for more protocols. It is, to put it mildly, a little Euro-centric (and not even completely suitable for Europe). Much of the advantage of Unicode is that one does not need to designate/ nominate a particular CCS or encoding and then maintain state for it... and that is a fairly large advantage. See also draft-klensin-unicode-escapes-03.txt(probably expired, but you should be able to find a copy somewhere -- I'll get back to it sometime soon) for a discussion of issues in ASCII encoding of multioctet character sets. The IRI spec may constrain things to encoding of octets, but that doesn't make it a good idea. If we are going to consider changes in this area, let's make them improvements. Locking in 8859-1 is not an improvement: it would, IMO, be better to deprecate its use and require explicit charset designation always if that is the only choice. john From discuss-bounces@apps.ietf.org Mon Aug 20 03:56:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN266-0004oc-HO; Mon, 20 Aug 2007 03:54:50 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IN265-0004oW-FI for discuss-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 03:54:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN265-0004oO-5n for discuss@apps.ietf.org; Mon, 20 Aug 2007 03:54:49 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN264-0005GY-Ly for discuss@apps.ietf.org; Mon, 20 Aug 2007 03:54:49 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id l7K7slET023209Mon, 20 Aug 2007 07:54:47 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1IN262-000IFR-00; Mon, 20 Aug 2007 08:54:46 +0100 Date: Mon, 20 Aug 2007 08:54:46 +0100 From: "Clive D.W. Feather" To: John C Klensin Subject: Re: Character encodings in headers [i74][was: Straw-man charter for http-bis] Message-ID: <20070820075446.GA68079@finch-staff-1.thus.net> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <6.0.0.20.2.20070610165356.0a69cec0@localhost> <088FB13E-F12F-4BE7-94FB-78B21C51512E@mnot.net> <157F4F253535B9C73F8EDC75@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157F4F253535B9C73F8EDC75@p3.JCK.COM> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Felix Sasaki , Richard Ishida , Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" , Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org John C Klensin said: > If we are going to consider changes in this area, let's make > them improvements. Locking in 8859-1 is not an improvement: it > would, IMO, be better to deprecate its use +1 -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From discuss-bounces@apps.ietf.org Mon Aug 20 03:57:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN27M-0005HO-M2; Mon, 20 Aug 2007 03:56:08 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IN27L-0005HJ-E7 for discuss-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 03:56:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN27L-0005HB-4K for discuss@apps.ietf.org; Mon, 20 Aug 2007 03:56:07 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN27J-0005IK-7Y for discuss@apps.ietf.org; Mon, 20 Aug 2007 03:56:07 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l7K7u2PL022758 for ; Mon, 20 Aug 2007 16:56:02 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 4012_cbba3b88_4ef2_11dc_822a_0014221fa3c9; Mon, 20 Aug 2007 16:56:01 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:59483) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 20 Aug 2007 16:53:16 +0900 Message-Id: <6.0.0.20.2.20070820162657.08bf55a0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 20 Aug 2007 16:54:20 +0900 To: Mark Nottingham From: Martin Duerst Subject: Re: Character encodings in headers [i74][was: Straw-man charter for http-bis] In-Reply-To: <088FB13E-F12F-4BE7-94FB-78B21C51512E@mnot.net> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <6.0.0.20.2.20070610165356.0a69cec0@localhost> <088FB13E-F12F-4BE7-94FB-78B21C51512E@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Richard Ishida , Apps Discuss , Felix Sasaki , "ietf-http-wg@w3.org Group" , Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello Mark, Thanks for giving this an issue number. At 12:40 07/08/20, Mark Nottingham wrote: >On 10/06/2007, at 6:05 PM, Martin Duerst wrote: >> - RFC 2616 prescribes that headers containing non-ASCII have to use >> either iso-8859-1 or RFC 2047. This is unnecessarily complex and >> not necessarily followed. At the least, new extensions should be >> allowed to specify that UTF-8 is used. > >My .02; > >I'm concerned about allowing UTF-8; it may break existing >implementations. > >I'd like to see the text just require that the actual character set >be 8859-1, but to allow individual extensions to nominate encodings >*like* 2047,without being restricted to it. What do you mean by "encodings *like* 2047"? And why do you think that UTF-8 may break existing implementations? UTF-8 has virtually the same footprint in terms of bytes as ISO-8859-1: All bytes above 0x7F may be used. Implementations that have to deal with ISO-8859-1 usually do this by just being 8-bit-transparent; that works for UTF-8, too. If your opinion is that UTF-8 cannot be allowed at all, then that's going to be a problem for cases where it's already in use, see e.g. earlier posts in the http list. It's easy to say "may break existing implementations", but in over 10 years of being involved in the Web, I haven't heard about that happening. If you or anybody have, please speak up. >For example, the encoding >specified in 3987 is appropriate for URIs. As one of the authors of RFC 3987, I know what you mean, but "the encoding specified in 3987" wouldn't be enough for a spec. Also, it's not really very well suited to the job, because %hh-encoding is used to escape any bytes, not only UTF-8, and there is a considerably length increase for some scripts. >However, it *has* to be >explicit; I've heard some people read this requirement and think that >they need to check *every* header for 2047 encoding. I have read it that way, too. If it can be safely argued that it was never intended that way, and that no harm is produced if this is restricted, then I'd befine with restricting it, because checking everything for 2047 is indeed tough, but I'd really like to make sure that this isn't creating problems. (i.e. that a careful examination of the various headers makes some reasonably conservative assumptions). >So, I think this means; > >1) Change > "Words of *TEXT MAY contain characters from character sets other >than ISO-8859-1 [22] only when encoded according to the rules of RFC >2047 [14]." >to > "Words of *TEXT MUST NOT contain characters from character sets >other than ISO-885901 [22]." >and, > >2) Identify headers that may have non-8859 There are many parts to ISO-8859, not just ISO-8859-1. >content and explicitly say >how to encode them (IRI, 2047, whatever; the existing ones will have >to be 2047, I believe), modifying their BNF to suit. > >3) When we document extensibility, require new headers to nominate >any encoding explicitly. If that includes UTF-8, I'd be fine with it. If it excludes UTF-8, I think that would be a problem. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Mon Aug 20 04:23:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2Vf-0007oi-4N; Mon, 20 Aug 2007 04:21:15 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IN2Ve-0007od-Hu for discuss-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 04:21:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2Ve-0007oV-8R for discuss@apps.ietf.org; Mon, 20 Aug 2007 04:21:14 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN2Vc-0005vi-C7 for discuss@apps.ietf.org; Mon, 20 Aug 2007 04:21:14 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l7K8L83d020446 for ; Mon, 20 Aug 2007 17:21:08 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 3fe8_4dd8e21a_4ef6_11dc_9e70_0014221fa3c9; Mon, 20 Aug 2007 17:21:08 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:37637) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 20 Aug 2007 17:18:22 +0900 Message-Id: <6.0.0.20.2.20070820170314.07449b20@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 20 Aug 2007 17:10:27 +0900 To: Keith Moore , Mark Nottingham From: Martin Duerst Subject: Re: Character encodings in headers [i74][was: Straw-man charter forhttp-bis] In-Reply-To: <46C93B36.7070503@cs.utk.edu> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <6.0.0.20.2.20070610165356.0a69cec0@localhost> <088FB13E-F12F-4BE7-94FB-78B21C51512E@mnot.net> <46C93B36.7070503@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Paul Hoffman , Apps Discuss , Felix Sasaki , "ietf-http-wg@w3.org Group" , Richard Ishida X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 15:56 07/08/20, Keith Moore wrote: >Mark Nottingham wrote: >> On 10/06/2007, at 6:05 PM, Martin Duerst wrote: >>> - RFC 2616 prescribes that headers containing non-ASCII have to use >>> either iso-8859-1 or RFC 2047. This is unnecessarily complex and >>> not necessarily followed. At the least, new extensions should be >>> allowed to specify that UTF-8 is used. >> >> My .02; >> >> I'm concerned about allowing UTF-8; it may break existing >> implementations. >concur. though at least it is possible to distinguish utf-8 from 8859-1. In practice indeed this can be done with high reliability; please see http://www.ifi.unizh.ch/mml/mduerst/papers/PDF/IUC11-UTF-8.pdf for details. For iso-8859-1, see in particular p. 21. >also, I'll note that supporting utf-8 in a way that is backward >compatible with existing implementations is almost certainly more >complex (and thus more costly, error-prone, etc) than supporting rfc 2047. Well, if "backwards compatible" means also supporting RFC 2047, then that's a tautology. If the choice is between UTF-8 and RFC 2047, however, then I'd take UTF-8 any time, because RFC 2047 includes UTF-8 as well as many other encodings. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Mon Aug 20 04:57:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN32v-0006uC-AW; Mon, 20 Aug 2007 04:55:37 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IN32t-0006u7-OX for discuss-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 04:55:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN32t-0006tz-Er for discuss@apps.ietf.org; Mon, 20 Aug 2007 04:55:35 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN32s-0006au-73 for discuss@apps.ietf.org; Mon, 20 Aug 2007 04:55:35 -0400 Received: from [127.0.0.1] (unknown [216.145.54.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 5C3065197C; Mon, 20 Aug 2007 04:55:27 -0400 (EDT) In-Reply-To: <157F4F253535B9C73F8EDC75@p3.JCK.COM> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <6.0.0.20.2.20070610165356.0a69cec0@localhost> <088FB13E-F12F-4BE7-94FB-78B21C51512E@mnot.net> <157F4F253535B9C73F8EDC75@p3.JCK.COM> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6B8E3D7A-71B8-4B8D-9625-2AB3C74A9072@mnot.net> Content-Transfer-Encoding: 7bit From: Mark Nottingham Subject: Re: Character encodings in headers [i74][was: Straw-man charter for http-bis] Date: Mon, 20 Aug 2007 18:55:10 +1000 To: John C Klensin X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -1.0 (-) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Richard Ishida , Apps Discuss , Felix Sasaki , "ietf-http-wg@w3.org Group" , Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org The (potential) problem is that an intermediary (for example) needs to be able to handle headers that it doesn't understand. If it's been built to store headers as iso-8859-1 strings as they pass through (a reasonable assumption, considering 2616), an unknown header with another encoding -- no matter how specified or flagged -- may break it. So, going forward, I completely agree with you, but in the case of HTTP, I think the horse has already bolted; it is effectively fixed to 8859-1, and we can't fix this in the right way without versioning the protocol. Or am I missing something? On 20/08/2007, at 5:22 PM, John C Klensin wrote: > Sigh. My own sense is that, going forward, we need to lose > 8859-N, not make it the default (or only) character set for more > protocols. It is, to put it mildly, a little Euro-centric (and > not even completely suitable for Europe). Much of the advantage > of Unicode is that one does not need to designate/ nominate a > particular CCS or encoding and then maintain state for it... and > that is a fairly large advantage. See also > draft-klensin-unicode-escapes-03.txt(probably expired, but you > should be able to find a copy somewhere -- I'll get back to it > sometime soon) for a discussion of issues in ASCII encoding of > multioctet character sets. The IRI spec may constrain things > to encoding of octets, but that doesn't make it a good idea. > > If we are going to consider changes in this area, let's make > them improvements. Locking in 8859-1 is not an improvement: it > would, IMO, be better to deprecate its use and require explicit > charset designation always if that is the only choice. -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Mon Aug 20 05:21:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN3Qj-0007pj-BL; Mon, 20 Aug 2007 05:20:13 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IN3Qi-0007pd-Pg for discuss-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 05:20:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN3Qi-0007pV-GA for discuss@apps.ietf.org; Mon, 20 Aug 2007 05:20:12 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN3Qg-00072t-GD for discuss@apps.ietf.org; Mon, 20 Aug 2007 05:20:12 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l7K9K5sd001210 for ; Mon, 20 Aug 2007 18:20:05 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 490a_89946826_4efe_11dc_83b2_0014221f2a2d; Mon, 20 Aug 2007 18:20:04 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49779) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 20 Aug 2007 18:17:18 +0900 Message-Id: <6.0.0.20.2.20070820181338.07260770@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 20 Aug 2007 18:18:30 +0900 To: Mark Nottingham , John C Klensin From: Martin Duerst Subject: Re: Character encodings in headers [i74][was: Straw-man charter for http-bis] In-Reply-To: <6B8E3D7A-71B8-4B8D-9625-2AB3C74A9072@mnot.net> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <6.0.0.20.2.20070610165356.0a69cec0@localhost> <088FB13E-F12F-4BE7-94FB-78B21C51512E@mnot.net> <157F4F253535B9C73F8EDC75@p3.JCK.COM> <6B8E3D7A-71B8-4B8D-9625-2AB3C74A9072@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Paul Hoffman , Apps Discuss , Felix Sasaki , "ietf-http-wg@w3.org Group" , Richard Ishida X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 17:55 07/08/20, Mark Nottingham wrote: >The (potential) problem is that an intermediary (for example) needs >to be able to handle headers that it doesn't understand. If it's been >built to store headers as iso-8859-1 strings as they pass through (a >reasonable assumption, considering 2616), an unknown header with >another encoding -- no matter how specified or flagged -- may break it. I think you present a valid scenario. However, storing headers as iso-8859-1 essentially means storing (and resending) them as bytes. If such an implementation gets UTF-8, it will just store and resend that as iso-8859-1, which means store and resend as bytes, which, from the viewpoint of that implementation, will be GIGO, but overall, will not cause any damage. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Mon Aug 20 06:05:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN46t-000576-Fi; Mon, 20 Aug 2007 06:03:47 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IN46s-00056w-PF for discuss-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 06:03:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN46s-00056l-FX for discuss@apps.ietf.org; Mon, 20 Aug 2007 06:03:46 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN46r-0007m1-5I for discuss@apps.ietf.org; Mon, 20 Aug 2007 06:03:46 -0400 Received: from [127.0.0.1] (unknown [216.145.54.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id D251051943; Mon, 20 Aug 2007 06:03:41 -0400 (EDT) In-Reply-To: <6.0.0.20.2.20070820162657.08bf55a0@localhost> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <6.0.0.20.2.20070610165356.0a69cec0@localhost> <088FB13E-F12F-4BE7-94FB-78B21C51512E@mnot.net> <6.0.0.20.2.20070820162657.08bf55a0@localhost> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6F4AC9A3-721E-418D-B0FA-D0223DCDFFF9@mnot.net> Content-Transfer-Encoding: 7bit From: Mark Nottingham Subject: Re: Character encodings in headers [i74][was: Straw-man charter for http-bis] Date: Mon, 20 Aug 2007 20:03:26 +1000 To: Martin Duerst X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -1.0 (-) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: Paul Hoffman , Apps Discuss , Felix Sasaki , "ietf-http-wg@w3.org Group" , Richard Ishida X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 20/08/2007, at 5:54 PM, Martin Duerst wrote: > What do you mean by "encodings *like* 2047"? And why do you think > that UTF-8 may break existing implementations? See previous message. > UTF-8 has virtually > the same footprint in terms of bytes as ISO-8859-1: All bytes > above 0x7F may be used. Implementations that have to deal with > ISO-8859-1 usually do this by just being 8-bit-transparent; > that works for UTF-8, too. If utf-8 is a subset of iso-8859-1, it would work; but I don't think that's the case (not that I'm an expert in this area, by any means). > If your opinion is that UTF-8 cannot be allowed at all, then > that's going to be a problem for cases where it's already in > use, see e.g. earlier posts in the http list. Sorry, I looked and didn't find anything. Can you give references? > It's easy to say "may break existing implementations", > but in over 10 years of being involved in the Web, I haven't > heard about that happening. If you or anybody have, please > speak up. I'm wary of changing fundamental things in HTTP like the charset for headers because nobody's heard of it breaking things. My experience has been that the people who show up in this forum and the others that we circulate in are the tip of a much larger iceberg of implementations, and we make such changes at our peril. In particular, performance-sensitive implementations like proxies often rely on particular data structures that are mandated by the specs for optimisation. As you point out, they'll probably store them as bytes, but they may not. Client and server APIs have been built that make (again, reasonable) assumptions about headers' character sets. In both cases, changing the spec may break those implementations. Yes, it's just "may", but the burden of proof should be on those who want to make the change. To that end, if UTF-8 were widely used in HTTP headers already, I wouldn't be so uncomfortable, but AFAIK they're few and far between. >> For example, the encoding >> specified in 3987 is appropriate for URIs. > > As one of the authors of RFC 3987, I know what you mean, but > "the encoding specified in 3987" wouldn't be enough for a spec. > Also, it's not really very well suited to the job, because > %hh-encoding is used to escape any bytes, not only UTF-8, > and there is a considerably length increase for some scripts. I know. I didn't say it was a great solution, just one that works. >> However, it *has* to be >> explicit; I've heard some people read this requirement and think that >> they need to check *every* header for 2047 encoding. > > I have read it that way, too. If it can be safely argued that > it was never intended that way, and that no harm is produced > if this is restricted, then I'd befine with restricting it, > because checking everything for 2047 is indeed tough, but > I'd really like to make sure that this isn't creating problems. > (i.e. that a careful examination of the various headers makes > some reasonably conservative assumptions). I think that's a great first step. Taking a glance at the header registry , there are about 30 headers that might conceivably need non-ASCII content. Of those, the vast majority have URIs as a payload, which means that if you want to change the encoding, you'll need to change their syntax pretty fundamentally -- an incompatible change. Of the remaining ones, I see (with ones that may IMO be a problem marked with a *): * WWW-Authenticate, Proxy-Authenticate -- as discussed elsewhere * Authorization, Proxy-Authorization -- as discussed elsewhere * Content-Disposition -- can contain a filename - Cookie, Cookie2, Set-Cookie -- can contain user data, but it's opaque, so servers can choose their own encoding strategy - Server, Via, User-Agent -- not usually presented to users - Warning - can contain warning text, not usually presented to users - From -- an e-mail address (and possibly a candidate for deprecation) My earlier proposal would have the effect of clarifying the use of RFC2047 encoding in those marked with "*" above. It sounds like you want to change the syntax of those headers to allow UTF-8, no? If so, the problem that I have with that is that no existing conformance-minded implementer could have looked at RFC2616 and said to themselves, "oh, I should use/expect UTF-8 there," while such a statement could quite easily have been made about RFC2047. Now, if everybody has gone off and used UTF-8 despite the RFC, I could see an argument for changing the spec to match reality, but I don't think that's the case here. If there were a huge win here -- e.g., lots of improvements in i18n and efficiency -- again, it might be persuasive. But, looking at the list above, the benefits of such a change don't seem overwhelming. Again, I'm not an i18n expert, so please educate me. >> So, I think this means; >> >> 1) Change >> "Words of *TEXT MAY contain characters from character sets other >> than ISO-8859-1 [22] only when encoded according to the rules of RFC >> 2047 [14]." >> to >> "Words of *TEXT MUST NOT contain characters from character sets >> other than ISO-885901 [22]." >> and, >> >> 2) Identify headers that may have non-8859 > > There are many parts to ISO-8859, not just ISO-8859-1. Sorry, just using shorthand. >> content and explicitly say >> how to encode them (IRI, 2047, whatever; the existing ones will have >> to be 2047, I believe), modifying their BNF to suit. >> >> 3) When we document extensibility, require new headers to nominate >> any encoding explicitly. > > If that includes UTF-8, I'd be fine with it. If it excludes > UTF-8, I think that would be a problem. In my view, the proxy case and the API case above both rule that out; we can't assume that deployed software is set up to produce, accept or process UTF-8. > Regards, Martin. Cheers, -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Mon Aug 20 06:30:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN4VE-0006ii-At; Mon, 20 Aug 2007 06:28:56 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IN4VD-0006ic-GR for discuss-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 06:28:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN4VD-0006iU-6y for discuss@apps.ietf.org; Mon, 20 Aug 2007 06:28:55 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN4VB-0008ED-TI for discuss@apps.ietf.org; Mon, 20 Aug 2007 06:28:55 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id l7KASojS010788Mon, 20 Aug 2007 10:28:51 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1IN4QY-000LNm-00; Mon, 20 Aug 2007 11:24:06 +0100 Date: Mon, 20 Aug 2007 11:24:06 +0100 From: "Clive D.W. Feather" To: Mark Nottingham Subject: Re: Character encodings in headers [i74][was: Straw-man charter for http-bis] Message-ID: <20070820102406.GN68079@finch-staff-1.thus.net> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <6.0.0.20.2.20070610165356.0a69cec0@localhost> <088FB13E-F12F-4BE7-94FB-78B21C51512E@mnot.net> <6.0.0.20.2.20070820162657.08bf55a0@localhost> <6F4AC9A3-721E-418D-B0FA-D0223DCDFFF9@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6F4AC9A3-721E-418D-B0FA-D0223DCDFFF9@mnot.net> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Richard Ishida , Apps Discuss , Felix Sasaki , "ietf-http-wg@w3.org Group" , Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Mark Nottingham said: >> UTF-8 has virtually >> the same footprint in terms of bytes as ISO-8859-1: All bytes >> above 0x7F may be used. Implementations that have to deal with >> ISO-8859-1 usually do this by just being 8-bit-transparent; >> that works for UTF-8, too. > If utf-8 is a subset of iso-8859-1, it would work; but I don't think > that's the case (not that I'm an expert in this area, by any means). It's not. Printable text in ISO-8859-n (for all n) consists of a sequence of characters, each of which is either: one octet in the range 20 to 7E one octet in the range A0 to FF Printable text in UTF-8 consists of a sequence of characters, each of which is either: one octet in the range 20 to 7E one octet in the range C2 to E4 followed by between 1 and 3 octets in the range 80 to BF (the first octet tells you how many [*]) In both cases, 20 to 7E are the ASCII characters. In both cases, codes like 09 (HTAB) and 0A (LF) have the same meaning. In ISO-8859-n the meaning of codes A0 to FF depends on the value of n. In UTF-8 each sequence has a unique meaning that never changes. The syntax in 2616 allows any octet in the range 20 to FF except 7F; both of these are subsets of that. (*) To be precise: one octet C2 to DF followed by one octet in the range 80 to BF, or one octet E0 to E4 followed by two octets in the range 80 to BF, or one octet F0 to F7 followed by three octets in the range 80 to BF. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From discuss-bounces@apps.ietf.org Mon Aug 20 06:30:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN4VO-0006mZ-Jf; Mon, 20 Aug 2007 06:29:06 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IN4VN-0006mU-Rg for discuss-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 06:29:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN4VN-0006mM-Hz for discuss@apps.ietf.org; Mon, 20 Aug 2007 06:29:05 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN4VM-0008EQ-7k for discuss@apps.ietf.org; Mon, 20 Aug 2007 06:29:05 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id l7KASsf4010817Mon, 20 Aug 2007 10:29:03 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1IN3Qk-000JfX-00; Mon, 20 Aug 2007 10:20:14 +0100 Date: Mon, 20 Aug 2007 10:20:14 +0100 From: "Clive D.W. Feather" To: Mark Nottingham Subject: Re: Character encodings in headers [i74][was: Straw-man charter for http-bis] Message-ID: <20070820092014.GH68079@finch-staff-1.thus.net> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <6.0.0.20.2.20070610165356.0a69cec0@localhost> <088FB13E-F12F-4BE7-94FB-78B21C51512E@mnot.net> <157F4F253535B9C73F8EDC75@p3.JCK.COM> <6B8E3D7A-71B8-4B8D-9625-2AB3C74A9072@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6B8E3D7A-71B8-4B8D-9625-2AB3C74A9072@mnot.net> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Paul Hoffman , Richard Ishida , Apps Discuss , Felix Sasaki , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Mark Nottingham said: > The (potential) problem is that an intermediary (for example) needs > to be able to handle headers that it doesn't understand. If it's been > built to store headers as iso-8859-1 strings as they pass through (a > reasonable assumption, considering 2616), an unknown header with > another encoding -- no matter how specified or flagged -- may break it. On the other hand, the *syntax* allows any valid UTF-8 sequence, since it doesn't forbid the octets %x80-9F. So it's unlikely that anything will break unless someone is being very strict in their checking. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From discuss-bounces@apps.ietf.org Mon Aug 20 09:06:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN6vV-0001BP-BU; Mon, 20 Aug 2007 09:04:13 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IN6vU-0001BK-MQ for discuss-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 09:04:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN6vU-0001BC-D0 for discuss@apps.ietf.org; Mon, 20 Aug 2007 09:04:12 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN6vT-0004aP-6Q for discuss@apps.ietf.org; Mon, 20 Aug 2007 09:04:12 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id DBDF31EE308; Mon, 20 Aug 2007 09:04:07 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAZBAeeORLDu; Mon, 20 Aug 2007 09:04:05 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 8F9971EE30E; Mon, 20 Aug 2007 09:03:59 -0400 (EDT) Message-ID: <46C99137.80007@cs.utk.edu> Date: Mon, 20 Aug 2007 09:03:51 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Martin Duerst Subject: Re: Character encodings in headers [i74][was: Straw-man charter forhttp-bis] References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <6.0.0.20.2.20070610165356.0a69cec0@localhost> <088FB13E-F12F-4BE7-94FB-78B21C51512E@mnot.net> <46C93B36.7070503@cs.utk.edu> <6.0.0.20.2.20070820170314.07449b20@localhost> In-Reply-To: <6.0.0.20.2.20070820170314.07449b20@localhost> X-Enigmail-Version: 0.95.2 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Felix Sasaki , Richard Ishida , Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" , Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> also, I'll note that supporting utf-8 in a way that is backward >> compatible with existing implementations is almost certainly more >> complex (and thus more costly, error-prone, etc) than supporting rfc 2047. >> > > Well, if "backwards compatible" means also supporting RFC 2047, > of course it does mean that, as you're not going to get rid of the need to interoperate with the installed base of clients and servers anytime soon. > If the choice is between UTF-8 and RFC 2047, > however, then I'd take UTF-8 any time, because RFC 2047 includes > UTF-8 as well as many other encodings. if we had the luxury of starting from scratch, I'd agree with you. though my (fuzzy) memory seems to say that at the time HTTP was standardized lots of people insisted on using 8859-1 rather than either ASCII or any form of Unicode - again for backward compatibility reasons. but how much of a problem is this really? From discuss-bounces@apps.ietf.org Mon Aug 20 10:39:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN8NZ-00048n-0r; Mon, 20 Aug 2007 10:37:17 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IN8NY-00048h-8k for discuss-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 10:37:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN8NX-00048Z-VV for discuss@apps.ietf.org; Mon, 20 Aug 2007 10:37:15 -0400 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN8NW-0006ma-JI for discuss@apps.ietf.org; Mon, 20 Aug 2007 10:37:15 -0400 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id KAA27449; Mon, 20 Aug 2007 10:36:35 -0400 (EDT) From: der Mouse Message-Id: <200708201436.KAA27449@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 20 Aug 2007 10:18:13 -0400 (EDT) To: discuss@apps.ietf.org, Felix Sasaki , ietf-http-wg@w3.org, Richard Ishida Subject: Re: Character encodings in headers [i74][was: Straw-man charter for http-bis] In-Reply-To: <6.0.0.20.2.20070820181338.07260770@localhost> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <6.0.0.20.2.20070610165356.0a69cec0@localhost> <088FB13E-F12F-4BE7-94FB-78B21C51512E@mnot.net> <157F4F253535B9C73F8EDC75@p3.JCK.COM> <6B8E3D7A-71B8-4B8D-9625-2AB3C74A9072@mnot.net> <6.0.0.20.2.20070820181338.07260770@localhost> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > I think you present a valid scenario. However, storing headers as > iso-8859-1 essentially means storing (and resending) them as bytes. Depends on how much checking is done. The C0 and C1 ranges are not valid 8859-x text (except for a few codes in C0, like HT), but, as Clive points out, C1 does, in general, occur in UTF-8-encoded text. I recognize there's a "who would bother to check" tendency. While I share it, I also believe the number of distinct implementations out there is large enough that anything permitted by the spec has probably been done (and, of course, a great many things not permitted by the spec, but I see no reason to care about compatability with them). In particular, any implementation whose native text encoding is not 8859-1 may be recoding headers into its native encoding for storage and back again on output, and that is almost certain to corrupt C1 octets. The only fix I can see for that is to do something like UTF-8, but tweaked to keep all octets in the ISO-8859-x printable space. I've ben unable to come up with a way of doing this by just changing the fixed bits in UTF-8; it seems to me to require putting only five (rather than six) bits of data in the second and later octets. (I suspect this wouldn't fly, simply because UTF-8 is too entrenched, but it's the only way I can see to be strictly compatible. It also has the disadvantage that part of the BMP needs four octets rather than the three that UTF-8 needs.) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Mon Aug 20 15:31:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INCwy-0005H6-H4; Mon, 20 Aug 2007 15:30:08 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1INCwx-0005Gz-Bo for discuss-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 15:30:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INCwx-0005Gr-2K for discuss@apps.ietf.org; Mon, 20 Aug 2007 15:30:07 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INCwv-0007F5-Qm for discuss@apps.ietf.org; Mon, 20 Aug 2007 15:30:07 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 78F0B1EE33D; Mon, 20 Aug 2007 15:30:04 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92o3Tzrf7heq; Mon, 20 Aug 2007 15:29:59 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 3BC3E1EE32B; Mon, 20 Aug 2007 15:29:58 -0400 (EDT) Message-ID: <46C9EBAA.8030608@cs.utk.edu> Date: Mon, 20 Aug 2007 15:29:46 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: der Mouse Subject: Re: Character encodings in headers [i74][was: Straw-man charter for http-bis] References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <6.0.0.20.2.20070610165356.0a69cec0@localhost> <088FB13E-F12F-4BE7-94FB-78B21C51512E@mnot.net> <157F4F253535B9C73F8EDC75@p3.JCK.COM> <6B8E3D7A-71B8-4B8D-9625-2AB3C74A9072@mnot.net> <6.0.0.20.2.20070820181338.07260770@localhost> <200708201436.KAA27449@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200708201436.KAA27449@Sparkle.Rodents.Montreal.QC.CA> X-Enigmail-Version: 0.95.2 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: discuss@apps.ietf.org, Felix Sasaki , ietf-http-wg@w3.org, Richard Ishida X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org der Mouse wrote: >> I think you present a valid scenario. However, storing headers as >> iso-8859-1 essentially means storing (and resending) them as bytes. >> > > Depends on how much checking is done. The C0 and C1 ranges are not > valid 8859-x text (except for a few codes in C0, like HT), but, as > Clive points out, C1 does, in general, occur in UTF-8-encoded text. > > I recognize there's a "who would bother to check" tendency. While I > share it, I also believe the number of distinct implementations out > there is large enough that anything permitted by the spec has probably > been done (and, of course, a great many things not permitted by the > spec, but I see no reason to care about compatability with them). In > particular, any implementation whose native text encoding is not 8859-1 > may be recoding headers into its native encoding for storage and back > again on output, and that is almost certain to corrupt C1 octets. I suspect that the problem is not so much transparency, as presentation. The larger set of things broken by allowing utf-8 in existing header fields (and to a lesser extent new fields) will not be things that forbid C1 octet values, but rather things that try to display those fields as if they were 8859/1. Translation of the presumed 8859/1 into other charsets is another version of the same problem. From discuss-bounces@apps.ietf.org Tue Aug 21 12:47:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INWrD-0005Rs-LE; Tue, 21 Aug 2007 12:45:31 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IN7oi-00035X-3g for discuss-confirm+ok@megatron.ietf.org; Mon, 20 Aug 2007 10:01:16 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IN7oh-00035O-Qb for discuss@apps.ietf.org; Mon, 20 Aug 2007 10:01:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN7gV-0004H4-MI for discuss@apps.ietf.org; Mon, 20 Aug 2007 09:52:47 -0400 Received: from mx-out.forthnet.gr ([193.92.150.103] helo=mx-out-04.forthnet.gr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN7gS-0005kj-NV for discuss@apps.ietf.org; Mon, 20 Aug 2007 09:52:47 -0400 Received: from mx-av-01.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-04.forthnet.gr (8.13.8/8.13.8) with ESMTP id l7KDqduw021850; Mon, 20 Aug 2007 16:52:39 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-01.forthnet.gr (8.14.1/8.14.1) with ESMTP id l7KDqctc019538; Mon, 20 Aug 2007 16:52:38 +0300 Received: from hell.hell.gr (ppp178-206.adsl.forthnet.gr [62.1.181.206]) by MX-IN-01.forthnet.gr (8.14.1/8.14.1) with ESMTP id l7KDqRhj018895; Mon, 20 Aug 2007 16:52:29 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=v13@priest.com; spf=neutral Authentication-Results: MX-IN-01.forthnet.gr header.from=v13@priest.com; sender-id=neutral From: Stefanos Harhalakis To: Martin Duerst Subject: Re: Character encodings in headers [i74][was: Straw-man charter =?iso-8859-7?q?for=09http-bis=5D?= Date: Mon, 20 Aug 2007 16:52:26 +0300 User-Agent: KMail/1.9.7 References: <6B8E3D7A-71B8-4B8D-9625-2AB3C74A9072@mnot.net> <6.0.0.20.2.20070820181338.07260770@localhost> In-Reply-To: <6.0.0.20.2.20070820181338.07260770@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708201652.26863.v13@priest.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-TMDA-Confirmed: Mon, 20 Aug 2007 10:01:15 -0400 X-Mailman-Approved-At: Tue, 21 Aug 2007 12:45:30 -0400 Cc: Paul Hoffman , Felix Sasaki , Richard Ishida , Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Monday 20 August 2007, Martin Duerst wrote: > At 17:55 07/08/20, Mark Nottingham wrote: > >The (potential) problem is that an intermediary (for example) needs > >to be able to handle headers that it doesn't understand. If it's been > >built to store headers as iso-8859-1 strings as they pass through (a > >reasonable assumption, considering 2616), an unknown header with > >another encoding -- no matter how specified or flagged -- may break it. > > I think you present a valid scenario. However, storing headers as > iso-8859-1 essentially means storing (and resending) them as bytes. > If such an implementation gets UTF-8, it will just store and > resend that as iso-8859-1, which means store and resend as bytes, > which, from the viewpoint of that implementation, will be GIGO, > but overall, will not cause any damage. My 2c: UTF-8 introduces a requirement that ISO8859-X encodings don't have. UTF-8 strings may be invalid, in which case a proper action may be needed (drop ?). Thus, all UTF-8 strings need to be validated. Apart from that, implementations may do various tricks like logging etc, where: a) strlen() is used - not unicode aware b) iconv() is used to convert ISO8859-1 to UTF-8 either for presentation or for internal storage (python or java perhaps?) From discuss-bounces@apps.ietf.org Tue Aug 21 12:53:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INWx1-0005aq-Et; Tue, 21 Aug 2007 12:51:31 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1INWx0-0005al-ID for discuss-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 12:51:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INWx0-0005ad-8a for discuss@apps.ietf.org; Tue, 21 Aug 2007 12:51:30 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INWwz-0000Vs-T3 for discuss@apps.ietf.org; Tue, 21 Aug 2007 12:51:30 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 5D8EB1EE375; Tue, 21 Aug 2007 12:51:28 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGKM-wqhBunK; Tue, 21 Aug 2007 12:51:28 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 0814A1EE2C0; Tue, 21 Aug 2007 12:51:20 -0400 (EDT) Message-ID: <46CB17F5.8070702@cs.utk.edu> Date: Tue, 21 Aug 2007 12:51:01 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Stefanos Harhalakis Subject: Re: Character encodings in headers [i74][was: Straw-man charter for http-bis] References: <6B8E3D7A-71B8-4B8D-9625-2AB3C74A9072@mnot.net> <6.0.0.20.2.20070820181338.07260770@localhost> <200708201652.26863.v13@priest.com> In-Reply-To: <200708201652.26863.v13@priest.com> X-Enigmail-Version: 0.95.2 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Felix Sasaki , Richard Ishida , Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" , Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > > My 2c: > > UTF-8 introduces a requirement that ISO8859-X encodings don't have. UTF-8 > strings may be invalid, in which case a proper action may be needed (drop ?). > Thus, all UTF-8 strings need to be validated. > no. the last thing we need in HTTP (or any protocol IMHO) is for intermediaries to try to be smarter than their endpoints. > Apart from that, implementations may do various tricks like logging etc, > where: > a) strlen() is used - not unicode aware > strlen works the same for utf-8 as for ascii, as long as what you care about is number of bytes in the string rather than, say, the amount of space it will take up when displayed. > b) iconv() is used to convert ISO8859-1 to UTF-8 either for presentation or > for internal storage (python or java perhaps?) valid point. Keith From discuss-bounces@apps.ietf.org Mon Aug 27 16:21:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPl44-0007Ap-TJ; Mon, 27 Aug 2007 16:20:00 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IPl42-0006zF-E6 for discuss-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 16:19:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPl42-0006xs-4F for discuss@apps.ietf.org; Mon, 27 Aug 2007 16:19:58 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPl40-0004FP-KB for discuss@apps.ietf.org; Mon, 27 Aug 2007 16:19:58 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 27 Aug 2007 21:19:49 +0100 Message-ID: <46D33212.10903@isode.com> Date: Mon, 27 Aug 2007 21:20:34 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: HTTP Working Group Subject: Re: HTTPBis BOF followup - should RFC 2817/2818 be in scope for the WG? References: <46BDE42A.2040808@isode.com> In-Reply-To: <46BDE42A.2040808@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Alexey Melnikov wrote: > Hi folks, > Answers to this question during the BOF were not conclusive, so I > would like to poll mailing list members on whether revision of RFC > 2817 (Upgrading to TLS Within HTTP/1.1) and RFC 2818 (HTTP Over TLS) > should be in scope for the proposed WG. > > Question: Should RFC 2817 and/or RFC 2818 revision be in scope for the > WG? > > Please chose one of the following answers: > > 1). No > 2). Yes, only add RFC 2818bis to the charter > 3). Yes, only add RFC 2817bis to the charter > 4). Yes, add both RFC 2817bis and RFC 2818bis to the charter > 5). Maybe (this includes "yes, but when the WG completes the currently > proposed milestones" and "yes, but this should be done in another WG") > 6). I have another opinion, which is .... > > Please send answers to the mailing list, or directly to me *and* Mark > Nottingham . > And of course feel free to ask clarifying questions/correct list of > answers. Folks, I've seen very little answers to my question. I would like to encourage people to be more active on this. I would also like to set a deadline for this question: please send your response before September 3rd. From discuss-bounces@apps.ietf.org Mon Aug 27 16:24:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPl6Q-0001QX-8Y; Mon, 27 Aug 2007 16:22:26 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IPl6P-0001Q4-EK for discuss-confirm+ok@megatron.ietf.org; Mon, 27 Aug 2007 16:22:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPl6P-0001Pp-4X for discuss@apps.ietf.org; Mon, 27 Aug 2007 16:22:25 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPl6N-0004Ir-TD for discuss@apps.ietf.org; Mon, 27 Aug 2007 16:22:25 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 27 Aug 2007 21:22:21 +0100 Message-ID: <46D332AD.5070702@isode.com> Date: Mon, 27 Aug 2007 21:23:09 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: HTTP Working Group Subject: Re: HTTPBis BOF followup - should RFC 2965 (cookie) be in scope for the WG? References: <46BDE53B.1070404@isode.com> In-Reply-To: <46BDE53B.1070404@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Alexey Melnikov wrote: > Hi folks, > Answers to this question during the BOF were not conclusive, so I > would like to poll mailing list members on whether revision of RFC > 2965 (HTTP State Management Mechanism) should be in scope for the > proposed WG. > > Question: Should RFC 2965 revision be in scope for the WG? > > Please chose one of the following answers: > > 1). No > 2). Yes > 3). Maybe (this includes "yes, but when the WG completes the currently > proposed milestones" and "yes, but this should be done in another WG") > 4). I have another opinion, which is .... > > Please send answers to the mailing list, or directly to me *and* Mark > Nottingham . > And of course feel free to ask clarifying questions/correct list of > answers. If you haven't replied to this question, please send your replies by September 3rd. Thanks, Alexey From discuss-bounces@apps.ietf.org Tue Aug 28 15:39:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ6tC-0005mE-CQ; Tue, 28 Aug 2007 15:38:14 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IQ6tA-0005iS-Ae for discuss-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 15:38:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ6tA-0005ha-0o for discuss@apps.ietf.org; Tue, 28 Aug 2007 15:38:12 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ6t8-0006Ws-OU for discuss@apps.ietf.org; Tue, 28 Aug 2007 15:38:11 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id B2E041EE2C8; Tue, 28 Aug 2007 15:38:09 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMGHYOLMjUkF; Tue, 28 Aug 2007 15:38:07 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id DC2B21EE2DE; Tue, 28 Aug 2007 15:38:02 -0400 (EDT) Message-ID: <46D4798A.5070501@cs.utk.edu> Date: Tue, 28 Aug 2007 15:37:46 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: HTTPBis BOF followup - should RFC 2817/2818 be in scope for the WG? References: <46BDE42A.2040808@isode.com> <46D33212.10903@isode.com> In-Reply-To: <46D33212.10903@isode.com> X-Enigmail-Version: 0.95.2 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Apps Discuss , HTTP Working Group X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org I'm thinking that these are security RFCs and perhaps not proper scope for an apps group. however I don't know why an httpbis group shouldn't make recommendations for things to change in these RFCs if it can identify problems with them. Keith >> Hi folks, >> Answers to this question during the BOF were not conclusive, so I >> would like to poll mailing list members on whether revision of RFC >> 2817 (Upgrading to TLS Within HTTP/1.1) and RFC 2818 (HTTP Over TLS) >> should be in scope for the proposed WG. >> >> Question: Should RFC 2817 and/or RFC 2818 revision be in scope for >> the WG? >> >> Please chose one of the following answers: >> >> 1). No >> 2). Yes, only add RFC 2818bis to the charter >> 3). Yes, only add RFC 2817bis to the charter >> 4). Yes, add both RFC 2817bis and RFC 2818bis to the charter >> 5). Maybe (this includes "yes, but when the WG completes the >> currently proposed milestones" and "yes, but this should be done in >> another WG") >> 6). I have another opinion, which is .... >> >> Please send answers to the mailing list, or directly to me *and* Mark >> Nottingham . >> And of course feel free to ask clarifying questions/correct list of >> answers. > > Folks, I've seen very little answers to my question. I would like to > encourage people to be more active on this. > I would also like to set a deadline for this question: please send > your response before September 3rd. > > > From discuss-bounces@apps.ietf.org Tue Aug 28 15:43:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ6wV-0008I9-34; Tue, 28 Aug 2007 15:41:39 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IQ6wT-0008CD-Rl for discuss-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 15:41:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ6wT-0008Ac-Hk for discuss@apps.ietf.org; Tue, 28 Aug 2007 15:41:37 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ6wQ-0006bz-Th for discuss@apps.ietf.org; Tue, 28 Aug 2007 15:41:37 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 23D801EE2C8; Tue, 28 Aug 2007 15:41:33 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qrg3P9yIHxs; Tue, 28 Aug 2007 15:41:31 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id DB4741EE130; Tue, 28 Aug 2007 15:41:30 -0400 (EDT) Message-ID: <46D47A5B.3060601@cs.utk.edu> Date: Tue, 28 Aug 2007 15:41:15 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: HTTPBis BOF followup - should RFC 2965 (cookie) be in scope for the WG? References: <46BDE53B.1070404@isode.com> <46D332AD.5070702@isode.com> In-Reply-To: <46D332AD.5070702@isode.com> X-Enigmail-Version: 0.95.2 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Apps Discuss , HTTP Working Group X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org 3. maybe in particular, the group might consider that the privacy mechanisms specified have not worked so well, and consider whether there should be some additional protection for users against abuse of cookies. I don't think it would be appropriate for the WG to relax protections against cookie abuse. however this topic might be a rathole and might best be deferred until the group has completed other milestones. >> Hi folks, >> Answers to this question during the BOF were not conclusive, so I >> would like to poll mailing list members on whether revision of RFC >> 2965 (HTTP State Management Mechanism) should be in scope for the >> proposed WG. >> >> Question: Should RFC 2965 revision be in scope for the WG? >> >> Please chose one of the following answers: >> >> 1). No >> 2). Yes >> 3). Maybe (this includes "yes, but when the WG completes the >> currently proposed milestones" and "yes, but this should be done in >> another WG") >> 4). I have another opinion, which is .... >> >> Please send answers to the mailing list, or directly to me *and* Mark >> Nottingham . >> And of course feel free to ask clarifying questions/correct list of >> answers. > > If you haven't replied to this question, please send your replies by > September 3rd. > > Thanks, > Alexey > > > > From discuss-bounces@apps.ietf.org Thu Aug 30 11:21:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQloG-0003Bx-KZ; Thu, 30 Aug 2007 11:19:52 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IQ56z-0000hJ-BL for discuss-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 13:44:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ56z-0000h9-1r for discuss@apps.ietf.org; Tue, 28 Aug 2007 13:44:21 -0400 Received: from mx-out.forthnet.gr ([193.92.150.103] helo=mx-out-01.forthnet.gr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ56x-0001lK-Dm for discuss@apps.ietf.org; Tue, 28 Aug 2007 13:44:21 -0400 Received: from mx-av-01.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.13.8/8.13.8) with ESMTP id l7SHiIAk015441; Tue, 28 Aug 2007 20:44:18 +0300 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-01.forthnet.gr (8.14.1/8.14.1) with ESMTP id l7SHiI0Z000850; Tue, 28 Aug 2007 20:44:18 +0300 Received: from hell.hell.gr (ppp169-175.adsl.forthnet.gr [62.1.163.175]) by MX-IN-04.forthnet.gr (8.14.1/8.14.1) with ESMTP id l7SHiBDi022382; Tue, 28 Aug 2007 20:44:11 +0300 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=v13@priest.com; spf=neutral Authentication-Results: MX-IN-04.forthnet.gr header.from=v13@priest.com; sender-id=neutral From: Stefanos Harhalakis To: Alexey Melnikov Subject: Re: HTTPBis BOF followup - should RFC 2965 (cookie) be in scope for the WG? Date: Tue, 28 Aug 2007 20:44:10 +0300 User-Agent: KMail/1.9.7 References: <46BDE53B.1070404@isode.com> <46D332AD.5070702@isode.com> <200708282004.49749.v13@priest.com> In-Reply-To: <200708282004.49749.v13@priest.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708282044.10419.v13@priest.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Thu, 30 Aug 2007 11:19:51 -0400 Cc: Apps Discuss , HTTP Working Group X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Tuesday 28 August 2007, Stefanos Harhalakis wrote: > On Monday 27 August 2007, Alexey Melnikov wrote: > > Alexey Melnikov wrote: > > > Hi folks, > > > Answers to this question during the BOF were not conclusive, so I > > > would like to poll mailing list members on whether revision of RFC > > > 2965 (HTTP State Management Mechanism) should be in scope for the > > > proposed WG. > > > > > > Question: Should RFC 2965 revision be in scope for the WG? > > > > > > Please chose one of the following answers: > > > > > > 1). No > > > 2). Yes > > > 3). Maybe (this includes "yes, but when the WG completes the currently > > > proposed milestones" and "yes, but this should be done in another WG") > > > 4). I have another opinion, which is .... > > > > > > Please send answers to the mailing list, or directly to me *and* Mark > > > Nottingham . > > > And of course feel free to ask clarifying questions/correct list of > > > answers. > > > > If you haven't replied to this question, please send your replies by > > September 3rd. > > I don't know if I'm supposed to vote, but I'd suggest 1 (No). The rationale > can be summarized in the question: "Why yes?". Sorry for replying to self but I'd like to change that From discuss-bounces@apps.ietf.org Thu Aug 30 11:21:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQloG-0003Bx-KZ; Thu, 30 Aug 2007 11:19:52 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IQ56z-0000hJ-BL for discuss-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 13:44:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ56z-0000h9-1r for discuss@apps.ietf.org; Tue, 28 Aug 2007 13:44:21 -0400 Received: from mx-out.forthnet.gr ([193.92.150.103] helo=mx-out-01.forthnet.gr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ56x-0001lK-Dm for discuss@apps.ietf.org; Tue, 28 Aug 2007 13:44:21 -0400 Received: from mx-av-01.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.13.8/8.13.8) with ESMTP id l7SHiIAk015441; Tue, 28 Aug 2007 20:44:18 +0300 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-01.forthnet.gr (8.14.1/8.14.1) with ESMTP id l7SHiI0Z000850; Tue, 28 Aug 2007 20:44:18 +0300 Received: from hell.hell.gr (ppp169-175.adsl.forthnet.gr [62.1.163.175]) by MX-IN-04.forthnet.gr (8.14.1/8.14.1) with ESMTP id l7SHiBDi022382; Tue, 28 Aug 2007 20:44:11 +0300 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=v13@priest.com; spf=neutral Authentication-Results: MX-IN-04.forthnet.gr header.from=v13@priest.com; sender-id=neutral From: Stefanos Harhalakis To: Alexey Melnikov Subject: Re: HTTPBis BOF followup - should RFC 2965 (cookie) be in scope for the WG? Date: Tue, 28 Aug 2007 20:44:10 +0300 User-Agent: KMail/1.9.7 References: <46BDE53B.1070404@isode.com> <46D332AD.5070702@isode.com> <200708282004.49749.v13@priest.com> In-Reply-To: <200708282004.49749.v13@priest.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708282044.10419.v13@priest.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Thu, 30 Aug 2007 11:19:51 -0400 Cc: Apps Discuss , HTTP Working Group X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Tuesday 28 August 2007, Stefanos Harhalakis wrote: > On Monday 27 August 2007, Alexey Melnikov wrote: > > Alexey Melnikov wrote: > > > Hi folks, > > > Answers to this question during the BOF were not conclusive, so I > > > would like to poll mailing list members on whether revision of RFC > > > 2965 (HTTP State Management Mechanism) should be in scope for the > > > proposed WG. > > > > > > Question: Should RFC 2965 revision be in scope for the WG? > > > > > > Please chose one of the following answers: > > > > > > 1). No > > > 2). Yes > > > 3). Maybe (this includes "yes, but when the WG completes the currently > > > proposed milestones" and "yes, but this should be done in another WG") > > > 4). I have another opinion, which is .... > > > > > > Please send answers to the mailing list, or directly to me *and* Mark > > > Nottingham . > > > And of course feel free to ask clarifying questions/correct list of > > > answers. > > > > If you haven't replied to this question, please send your replies by > > September 3rd. > > I don't know if I'm supposed to vote, but I'd suggest 1 (No). The rationale > can be summarized in the question: "Why yes?". Sorry for replying to self but I'd like to change that to 4: Discuss it in the list first. Then, maybe vote for '3'. After reading the minutes (again), I understand that this will only change RFC 2695 to 'become' the Netscape doc. So, I don't actually see it as a hi priority issue, thinking that a well accepted document already exists (Netscape) and there is no confusion. Also, shouldn't this become a new RFC that will replace 2695? From discuss-bounces@apps.ietf.org Thu Aug 30 11:21:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQlo8-00033h-Fo; Thu, 30 Aug 2007 11:19:44 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IQ4V8-0002m9-Od for discuss-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 13:05:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ4V8-0002lb-EU for discuss@apps.ietf.org; Tue, 28 Aug 2007 13:05:14 -0400 Received: from mx-out.forthnet.gr ([193.92.150.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ4V6-0000KW-Ex for discuss@apps.ietf.org; Tue, 28 Aug 2007 13:05:14 -0400 Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-02.forthnet.gr (8.14.0/8.14.0) with ESMTP id l7SH4rhd023009; Tue, 28 Aug 2007 20:04:53 +0300 Received: from MX-IN-03.forthnet.gr (mx-in-03.forthnet.gr [193.92.150.26]) by mx-av-04.forthnet.gr (8.14.1/8.14.1) with ESMTP id l7SH4rG3007155; Tue, 28 Aug 2007 20:04:53 +0300 Received: from hell.hell.gr (ppp169-175.adsl.forthnet.gr [62.1.163.175]) by MX-IN-03.forthnet.gr (8.14.1/8.14.1) with ESMTP id l7SH4old011649; Tue, 28 Aug 2007 20:04:51 +0300 From: Stefanos Harhalakis To: Alexey Melnikov Subject: Re: HTTPBis BOF followup - should RFC 2965 (cookie) be in scope for the WG? Date: Tue, 28 Aug 2007 20:04:49 +0300 User-Agent: KMail/1.9.7 References: <46BDE53B.1070404@isode.com> <46D332AD.5070702@isode.com> In-Reply-To: <46D332AD.5070702@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708282004.49749.v13@priest.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Thu, 30 Aug 2007 11:19:43 -0400 Cc: Apps Discuss , HTTP Working Group X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Monday 27 August 2007, Alexey Melnikov wrote: > Alexey Melnikov wrote: > > Hi folks, > > Answers to this question during the BOF were not conclusive, so I > > would like to poll mailing list members on whether revision of RFC > > 2965 (HTTP State Management Mechanism) should be in scope for the > > proposed WG. > > > > Question: Should RFC 2965 revision be in scope for the WG? > > > > Please chose one of the following answers: > > > > 1). No > > 2). Yes > > 3). Maybe (this includes "yes, but when the WG completes the currently > > proposed milestones" and "yes, but this should be done in another WG") > > 4). I have another opinion, which is .... > > > > Please send answers to the mailing list, or directly to me *and* Mark > > Nottingham . > > And of course feel free to ask clarifying questions/correct list of > > answers. > > If you haven't replied to this question, please send your replies by > September 3rd. I don't know if I'm supposed to vote, but I'd suggest 1 (No). The rationale can be summarized in the question: "Why yes?". to 4: Discuss it in the list first. Then, maybe vote for '3'. After reading the minutes (again), I understand that this will only change RFC 2695 to 'become' the Netscape doc. So, I don't actually see it as a hi priority issue, thinking that a well accepted document already exists (Netscape) and there is no confusion. Also, shouldn't this become a new RFC that will replace 2695? From discuss-bounces@apps.ietf.org Thu Aug 30 11:21:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQlo8-00033h-Fo; Thu, 30 Aug 2007 11:19:44 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IQ4V8-0002m9-Od for discuss-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 13:05:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ4V8-0002lb-EU for discuss@apps.ietf.org; Tue, 28 Aug 2007 13:05:14 -0400 Received: from mx-out.forthnet.gr ([193.92.150.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ4V6-0000KW-Ex for discuss@apps.ietf.org; Tue, 28 Aug 2007 13:05:14 -0400 Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-02.forthnet.gr (8.14.0/8.14.0) with ESMTP id l7SH4rhd023009; Tue, 28 Aug 2007 20:04:53 +0300 Received: from MX-IN-03.forthnet.gr (mx-in-03.forthnet.gr [193.92.150.26]) by mx-av-04.forthnet.gr (8.14.1/8.14.1) with ESMTP id l7SH4rG3007155; Tue, 28 Aug 2007 20:04:53 +0300 Received: from hell.hell.gr (ppp169-175.adsl.forthnet.gr [62.1.163.175]) by MX-IN-03.forthnet.gr (8.14.1/8.14.1) with ESMTP id l7SH4old011649; Tue, 28 Aug 2007 20:04:51 +0300 From: Stefanos Harhalakis To: Alexey Melnikov Subject: Re: HTTPBis BOF followup - should RFC 2965 (cookie) be in scope for the WG? Date: Tue, 28 Aug 2007 20:04:49 +0300 User-Agent: KMail/1.9.7 References: <46BDE53B.1070404@isode.com> <46D332AD.5070702@isode.com> In-Reply-To: <46D332AD.5070702@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708282004.49749.v13@priest.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Thu, 30 Aug 2007 11:19:43 -0400 Cc: Apps Discuss , HTTP Working Group X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Monday 27 August 2007, Alexey Melnikov wrote: > Alexey Melnikov wrote: > > Hi folks, > > Answers to this question during the BOF were not conclusive, so I > > would like to poll mailing list members on whether revision of RFC > > 2965 (HTTP State Management Mechanism) should be in scope for the > > proposed WG. > > > > Question: Should RFC 2965 revision be in scope for the WG? > > > > Please chose one of the following answers: > > > > 1). No > > 2). Yes > > 3). Maybe (this includes "yes, but when the WG completes the currently > > proposed milestones" and "yes, but this should be done in another WG") > > 4). I have another opinion, which is .... > > > > Please send answers to the mailing list, or directly to me *and* Mark > > Nottingham . > > And of course feel free to ask clarifying questions/correct list of > > answers. > > If you haven't replied to this question, please send your replies by > September 3rd. I don't know if I'm supposed to vote, but I'd suggest 1 (No). The rationale can be summarized in the question: "Why yes?".