From owner-ietf-message-xml Tue Jan 28 11:00:40 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0SJ0e108617 for ietf-message-xml-bks; Tue, 28 Jan 2003 11:00:40 -0800 (PST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0SJ0do08604 for ; Tue, 28 Jan 2003 11:00:39 -0800 (PST) Received: from GK-VAIO.NineByNine.org (IDENT:root@localhost [127.0.0.1]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id LAA14146 for ; Tue, 28 Jan 2003 11:00:23 -0800 Message-Id: <5.1.0.14.2.20030128152224.0326f4c0@127.0.0.1> X-Sender: gk@127.0.0.1 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 28 Jan 2003 15:22:51 +0000 To: ietf-message-xml@imc.org From: Graham Klyne Subject: Reviving draft-klyne-message-xml Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've submitted the long-expired XML message format Internet draft for republication. I'll copy the announcement here when it is published. #g ------------------- Graham Klyne From owner-ietf-message-xml Tue Jan 28 11:00:41 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0SJ0fM08618 for ietf-message-xml-bks; Tue, 28 Jan 2003 11:00:41 -0800 (PST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0SJ0eo08612 for ; Tue, 28 Jan 2003 11:00:40 -0800 (PST) Received: from GK-VAIO.ninebynine.org (IDENT:root@localhost [127.0.0.1]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id LAA14143 for ; Tue, 28 Jan 2003 11:00:23 -0800 Message-Id: <5.1.0.14.2.20030128152315.03274c20@127.0.0.1> X-Sender: gk-lists@127.0.0.1 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 28 Jan 2003 18:42:56 +0000 To: XML message format From: Graham Klyne Subject: Fwd: I-D ACTION:draft-klyne-message-xml-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is the announcement of re-publication of the draft. I have received some comments which I shall (with the commentators' permission) reply to on this list in due course. #g -- >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-klyne-message-xml-00.txt >Date: Mon, 27 Jan 2003 06:44:18 -0500 >Sender: owner-ietf-announce@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : An XML format for mail and other messages > Author(s) : G. Klyne > Filename : draft-klyne-message-xml-00.txt > Pages : 28 > Date : 2003-1-24 > >This document describes a coding of email and other messages in >XML. This coding is intended for use by XML applications that >exchange information about such messages. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-klyne-message-xml-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-klyne-message-xml-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-klyne-message-xml-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-1-24113144.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-klyne-message-xml-00.txt > > ------------------- Graham Klyne From owner-ietf-message-xml Wed Jan 29 08:03:50 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0TG3or17978 for ietf-message-xml-bks; Wed, 29 Jan 2003 08:03:50 -0800 (PST) Received: from joker.webarchitects.co.uk (mkdoc.demon.co.uk [62.49.20.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0TG3mo17974 for ; Wed, 29 Jan 2003 08:03:48 -0800 (PST) Received: by joker.webarchitects.co.uk (Postfix, from userid 501) id 04484FA50; Wed, 29 Jan 2003 16:03:41 +0000 (GMT) Date: Wed, 29 Jan 2003 16:03:41 +0000 From: Chris Croome To: XML message format Subject: Some things I'm interesting in using this for Message-ID: <20030129160341.GQ3680@webarchitects.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Uptime: 11:02am up 24 days, 19:49, 2 users, load average: 0.78, 1.33, 0.76 X-PGP-Key: http://chris.croome.net/pgp.html X-PGP-KeyID: 0x8BB2DE91 Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi I guess this list is now 'live' now since the message to the RDF interest list. Two things that I'm interested is using this format for are for putting info from email headers into RSS via an updated version of this draft document: http://purl.org/rss/1.0/modules/email/ And also to allow XML templates for email messages to be created using Petal [1] (a attribute templating system based on Zope's TAL). At the moment we are using a template based on XMTP [2]. If anyone is interested in further details on these things just shout. Chris [1] http://search.cpan.org/search?query=Petal [2] http://www.openhealth.org/xmtp/ -- Chris Croome web design http://www.webarchitects.co.uk/ web content management http://mkdoc.com/ everything else http://chris.croome.net/ From owner-ietf-message-xml Wed Feb 5 09:34:57 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h15HYv021357 for ietf-message-xml-bks; Wed, 5 Feb 2003 09:34:57 -0800 (PST) Received: from smtp.laposte.net (smtp.laposte.net [213.30.181.7] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15HYud21353 for ; Wed, 5 Feb 2003 09:34:56 -0800 (PST) Received: from laposte.net (80.13.253.16) by smtp.laposte.net (6.0.053) (authenticated as Jerome.Huchard@laposte.net) id 3E35DC0D0016CDCF for ietf-message-xml@imc.org; Wed, 5 Feb 2003 18:34:52 +0100 Message-ID: <3E414B3B.4020402@laposte.net> Date: Wed, 05 Feb 2003 18:34:51 +0100 From: =?ISO-8859-1?Q?J=E9r=F4me_Huchard?= User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-message-xml@imc.org Subject: XMIME Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, Do you know about this Draft: http://www.openebxml.org/realization/components/comp_xlif/doc/xmime-20010716.html Is it one of the inputs for draft-klyne-message-xml-00.txt? regards, Jerome. From owner-ietf-message-xml Thu Feb 6 03:37:57 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16BbvZ26540 for ietf-message-xml-bks; Thu, 6 Feb 2003 03:37:57 -0800 (PST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16Bbtd26533 for ; Thu, 6 Feb 2003 03:37:55 -0800 (PST) Received: from GK-VAIO.ninebynine.org (IDENT:root@localhost [127.0.0.1]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id DAA16103; Thu, 6 Feb 2003 03:37:33 -0800 Message-Id: <5.1.0.14.2.20030206094515.00a9add0@127.0.0.1> X-Sender: gk-lists@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Feb 2003 09:50:35 +0000 To: =?iso-8859-1?Q?J=E9r=F4me?= Huchard From: Graham Klyne Subject: Re: XMIME Cc: ietf-message-xml@imc.org In-Reply-To: <3E414B3B.4020402@laposte.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h16Bbtd26534 Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: No, I did not know about that draft. Thanks for pointing it out. As it happens, it embodies a quite different approach to identifying header fields: the approach in draft-klyne-message-xml aims to embody the header field names as XML element names, namespace-qualified. The other draft uses a fixed set of element names and includes header field names as attribute values. I won't claim that one approach is fundamentally better than the other: I can see advantages in each. I prefer the approach I've suggested because it maps more closely to what people might expect message data in XML to look like, and I think is generally more compact by avoiding an un-needed lavel of indirection. #g -- At 06:34 PM 2/5/03 +0100, Jérôme Huchard wrote: >Hi, >Do you know about this Draft: >http://www.openebxml.org/realization/components/comp_xlif/doc/xmime-20010716.html > >Is it one of the inputs for draft-klyne-message-xml-00.txt? > >regards, Jerome. ------------------- Graham Klyne From owner-ietf-message-xml Thu Feb 6 07:40:24 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16FeOl14533 for ietf-message-xml-bks; Thu, 6 Feb 2003 07:40:24 -0800 (PST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16FeNd14528 for ; Thu, 6 Feb 2003 07:40:23 -0800 (PST) Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id HAA25053; Thu, 6 Feb 2003 07:39:40 -0800 Date: Thu, 6 Feb 2003 07:20:32 -0800 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <3787552123.20030206072032@brandenburg.com> To: =?ISO-8859-1?B?Suly9G1lIEh1Y2hhcmQ=?= CC: ietf-message-xml@imc.org Subject: Re: XMIME In-Reply-To: <5.1.0.14.2.20030206094515.00a9add0@127.0.0.1> References: <5.1.0.14.2.20030206094515.00a9add0@127.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: FOlks,, Thursday, February 6, 2003, 1:50:35 AM, you wrote: GK> As it happens, it embodies a quite different approach to identifying header GK> fields: the approach in draft-klyne-message-xml aims to embody the header GK> field names as XML element names, namespace-qualified. The other draft GK> uses a fixed set of element names and includes header field names as GK> attribute values. To carry Graham's reference to people's "expectations", a bit further: One essentially treats header names as something to encapsulate in XML. This might be good for quick "tunneling" of 822 data. The other integrates header names fully into XML processing. This is good for long-term. It allows email headers to benefit from the rich repertoire of XML tools. Think of it this way: Is the goal simple to interface to the RFC822/RFC821 world, or is the goal to emulate it in XML, permitting a "native" XML environment for email headers? Another way of saying the latter: What would the XML look like if we were creating email headers from scratch, starting with an XML syntax? The result would have the same semantics as RFC822/RFC821 headers, but the syntax would be entirely native XML. d/ -- Dave Brandenburg InternetWorking t +1.408.246.8253; f +1.408.850.1850 From owner-ietf-message-xml Thu Feb 6 12:28:43 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16KShL29835 for ietf-message-xml-bks; Thu, 6 Feb 2003 12:28:43 -0800 (PST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16KSgd29831 for ; Thu, 6 Feb 2003 12:28:42 -0800 (PST) Received: from GK-VAIO.NineByNine.org (IDENT:root@localhost [127.0.0.1]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id MAA07511; Thu, 6 Feb 2003 12:28:17 -0800 Message-Id: <5.1.0.14.2.20030206181008.00a1ed90@127.0.0.1> X-Sender: gk@127.0.0.1 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Feb 2003 18:12:26 +0000 To: "Jon Hanna" From: Graham Klyne Subject: RE: XML message format draft Cc: ietf-message-xml@imc.org In-Reply-To: References: <20030121100951.GB31257@webarchitects.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:34 PM 1/21/03 +0000, Jon Hanna wrote: >One thing I noticed is that it is defined with reference to RFC822. RFC822 >was obsoleted by RFC2822. In particular the former is not Y2K compliant. Yes, I agree. RFC2822 should be cited now. As for time format, I'd like to move to a generic ISO8601-based form per RFC 3339 [1] or XML schema [2]. #g -- [1] http://www.ietf.org/rfc/rfc3339.txt [2] http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime ------------------- Graham Klyne From owner-ietf-message-xml Thu Feb 6 12:28:42 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16KSgs29829 for ietf-message-xml-bks; Thu, 6 Feb 2003 12:28:42 -0800 (PST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16KSfd29825 for ; Thu, 6 Feb 2003 12:28:41 -0800 (PST) Received: from GK-VAIO.NineByNine.org (IDENT:root@localhost [127.0.0.1]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id MAA07523 for ; Thu, 6 Feb 2003 12:28:26 -0800 Message-Id: <5.1.0.14.2.20030206182119.00a11420@127.0.0.1> X-Sender: gk@127.0.0.1 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Feb 2003 18:24:55 +0000 To: XML message format From: Graham Klyne Subject: Haystack? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It's been suggested to me that MIT's haystack project [1] may have some experience relevant to this message format work. I've taken a quick look, and it seems to me that the focus of Haystack is higher level. Apart from mentioning that it uses RDF, I can find no description or commentary about the email format used. Does anyone on the list know of any Haystack experience that might be relevant? #g -- [1] http://haystack.lcs.mit.edu/ ------------------- Graham Klyne From owner-ietf-message-xml Thu Feb 6 12:28:41 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16KSfA29823 for ietf-message-xml-bks; Thu, 6 Feb 2003 12:28:41 -0800 (PST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16KSdd29819 for ; Thu, 6 Feb 2003 12:28:39 -0800 (PST) Received: from GK-VAIO.NineByNine.org (IDENT:root@localhost [127.0.0.1]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id MAA07504; Thu, 6 Feb 2003 12:28:11 -0800 Message-Id: <5.1.0.14.2.20030206172630.00a0e920@127.0.0.1> X-Sender: gk@127.0.0.1 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Feb 2003 18:09:32 +0000 To: Chris Croome From: Graham Klyne Subject: Re: XML message format draft Cc: ietf-message-xml@imc.org In-Reply-To: <20030121100951.GB31257@webarchitects.co.uk> References: <5.1.0.14.2.20030120191559.00a2c190@127.0.0.1> <5.1.0.14.2.20020911214829.0399e630@127.0.0.1> <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <1031329936.12734.3951.camel@dirk> <3D78DDCD.60000@textuality.com> <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <5.1.0.14.2.20020911214829.0399e630@127.0.0.1> <5.1.0.14.2.20030120191559.00a2c190@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Chris, Now we've a discussion list running, I'll pick up your earlier comment... At 10:09 AM 1/21/03 +0000, Chris Croome wrote: >The RSS email module initial draft is here: > > http://purl.org/rss/1.0/modules/email/ > >One initial thing that struck me from your draft is the use of URNs >rather than URIs for namespaces -- I'm not going to get into a argument >about this but some involved with RSS might since all the other modules >use URIs, but I see that this in on the list of things to think about >:-) First, a nit: URNs *are* URIs; they just happen to use urn: scheme name. That said, I think I recognize the point you're really making. Technically, I think using either urn: [1] or http: [2] URIs can work just fine. And I understand the reasons for preferring http (though the W3C TAG is locked in a debate that could affect this). My own preference for a urn: form here is a reflection that this specification is intended to closely reflect some IETF specifications, and the URIs used should be within IETF/IANA change-control. At the present time, as far as I am aware, IETF/IANA are not signed up to the "cool URIs don't change" [3] commitment needed for http: URIs to be sufficiently stable. Further, I wish to leverage the message header registry proposal [4] that I believe is on its way to being a BCP. Of course, nobody is prevented from using this message framework to include non-IETF header fields, and using their own URIs in whatever scheme. Indeed, I would expect applications that process this message format to do just this; e.g. a message content analysis system might use its own http: namespace URIs for headers that describe the result of such analysis. I think that's way cleaner than the old X-header approach used with RFC822, etc. ... And also, a quick comparison with the RSS module. while the broad approach is similar, there are a number of differences in the way some details are handled: (1) Addresses - this newer specification uses URIs for addresses rather than literal text. For mail messages, that's mailto: URIs. But the same structures might be used with other forms of address (e.g. IM), so there's greater extensibility here. Also, within this framework, I have defined an XML/RDF structure to represent email group addresses. (2) Date: I am hoping to bring this into line with more recent practice of using an ISO-derived format. [5] [6] (3) Message content: I aim to refer to this using a URI. A fragment-only can be used if the content is embedded (as in the RSS example), but also binary data may be stored externally to the XML and referenced by a full URI. One mechanism described is to use multipart/related [7], Content-id header fields [8] and cid: URIs [9]. I'm sure there are other differences. I'm mainly trying to give a sense of the key differences in approach so we can explore them. #g -- [1] http://www.ietf.org/rfc/rfc2141.txt [2] http://www.ietf.org/rfc/rfc2616.txt [3] http://www.w3.org/Provider/Style/URI.html [4] http://www.ietf.org/internet-drafts/draft-klyne-msghdr-registry-06.txt [5] http://www.ietf.org/rfc/rfc3339.txt [6] http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime [7] http://www.ietf.org/rfc/rfc2387.txt [8] http://www.ietf.org/rfc/rfc2045.txt [9] http://www.ietf.org/rfc/rfc2111.txt ------------------- Graham Klyne From owner-ietf-message-xml Thu Feb 6 14:48:30 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16MmUo03870 for ietf-message-xml-bks; Thu, 6 Feb 2003 14:48:30 -0800 (PST) Received: from mail.webarchitects.co.uk (owl.webarchitects.co.uk [195.10.230.119]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16MmSd03866 for ; Thu, 6 Feb 2003 14:48:29 -0800 (PST) Received: by mail.webarchitects.co.uk (Postfix, from userid 501) id BF6612B144; Thu, 6 Feb 2003 22:48:23 +0000 (GMT) Date: Thu, 6 Feb 2003 22:48:23 +0000 From: Chris Croome To: Graham Klyne Cc: ietf-message-xml@imc.org Subject: Re: XML message format draft Message-ID: <20030206224823.GB20949@webarchitects.co.uk> References: <5.1.0.14.2.20030120191559.00a2c190@127.0.0.1> <5.1.0.14.2.20020911214829.0399e630@127.0.0.1> <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <1031329936.12734.3951.camel@dirk> <3D78DDCD.60000@textuality.com> <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <5.1.0.14.2.20020911214829.0399e630@127.0.0.1> <5.1.0.14.2.20030120191559.00a2c190@127.0.0.1> <5.1.0.14.2.20030206172630.00a0e920@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030206172630.00a0e920@127.0.0.1> User-Agent: Mutt/1.4i X-Editor: VIM - Vi IMproved 5.7 - http://www.vim.org/ X-OS: Linux 2.2.20-2tr i686 X-Uptime: 10:27pm up 146 days, 12:16, 4 users, load average: 0.00, 0.03, 0.02 X-PGP-Key: http://chris.croome.net/pgp.html X-PGP-KeyID: 0x8BB2DE91 Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Graham On Thu 06-Feb-2003 at 06:09:32PM +0000, Graham Klyne wrote: > > First, a nit: URNs *are* URIs; they just happen to use urn: > scheme name. Yes, sorry I was being sloppy, I did mean HTTP URIs. > My own preference for a urn: form here is a reflection that this > specification is intended to closely reflect some IETF > specifications, and the URIs used should be within IETF/IANA > change-control. Fair enough, the only reason I could think of to use a http:// URI would be in order to have a useful document at the URI address -- but in the absence of any agreement on this there is no good reason not to use a urn:. > Of course, nobody is prevented from using this message framework > to include non-IETF header fields, and using their own URIs in > whatever scheme. Indeed, I would expect applications that process > this message format to do just this; e.g. a message content > analysis system might use its own http: namespace URIs for headers > that describe the result of such analysis. I think that's way > cleaner than the old X-header approach used with RFC822, etc. Yes, using namespaces for extensibility makes sense to me. > And also, a quick comparison with the RSS module. while the broad > approach is similar, there are a number of differences in the way > some details are handled: > > (1) Addresses - this newer specification uses URIs for addresses > rather than literal text. For mail messages, that's mailto: URIs. > But the same structures might be used with other forms of address > (e.g. IM), so there's greater extensibility here. I agree that this is better. > Also, within this framework, I have defined an XML/RDF structure > to represent email group addresses. Sorry I don't understand this, by email group do you mean email list? > (2) Date: I am hoping to bring this into line with more recent > practice of using an ISO-derived format. [5] [6] Sounds sensible. > (3) Message content: I aim to refer to this using a URI. A > fragment-only can be used if the content is embedded (as in the > RSS example), but also binary data may be stored externally to the > XML and referenced by a full URI. One mechanism described is to > use multipart/related [7], Content-id header fields [8] and cid: > URIs [9]. Good idea -- more sensible than encoding binary data in XML :-) > I'm sure there are other differences. I'm mainly trying to give a > sense of the key differences in approach so we can explore them. One other issue that has come up for me is the situation when XML is being used to generate plain text emails -- using case sensitive element names saves writing code to generate headers with the correct case from all lower case XML elements -- what do you think about this? Chris -- Chris Croome web design http://www.webarchitects.co.uk/ web content management http://mkdoc.com/ everything else http://chris.croome.net/ From owner-ietf-message-xml Fri Feb 7 03:44:21 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17BiLK24061 for ietf-message-xml-bks; Fri, 7 Feb 2003 03:44:21 -0800 (PST) Received: from mail01.svc.cra.dublin.eircom.net (mail01.svc.cra.dublin.eircom.net [159.134.118.17]) by above.proper.com (8.11.6/8.11.3) with SMTP id h17BiKd24057 for ; Fri, 7 Feb 2003 03:44:20 -0800 (PST) Received: (qmail 21835 messnum 119875 invoked from network[213.190.156.86/quake.spin.ie]); 7 Feb 2003 11:44:14 -0000 Received: from quake.spin.ie (HELO cerridwen) (213.190.156.86) by mail01.svc.cra.dublin.eircom.net (qp 21835) with SMTP; 7 Feb 2003 11:44:14 -0000 From: "Jon Hanna" To: Subject: RE: XML message format draft Date: Fri, 7 Feb 2003 11:45:23 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5.1.0.14.2.20030206181008.00a1ed90@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > As for time format, I'd like to move to a generic ISO8601-based form per > RFC 3339 [1] or XML schema [2]. > > #g > -- > > [1] http://www.ietf.org/rfc/rfc3339.txt > > [2] http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime Agreed. I would suggest that we define a datetime which: 1. Is a subset of those allowed in the two works cited above, and also in NOTE-datetime (commonly referred to as W3CDTF), and as such also compatible with Dublin Core's W3CDTF (which is just a reuse of the former, with a DC-supplied URI). 2. Had the same range and precision as that used in RFC2822. 3. Was always expressed in terms of UTC/GMT. As such we would have a datetime format expressed as the following ABNF: date-time = full-date "T" UTC-time full-date = date-fullyear "-" date-month "-" date-mday date-fullyear = 4DIGIT date-month = 2DIGIT ; 01-12 date-mday = 2DIGIT ; 01-31 UTC-time = time-hour ":" time-minute ":" time-second "Z" time-hour = 2DIGIT ; 00-23 time-minute = 2DIGIT ; 00-59 time-second = 2DIGIT ; 00-60 This format can be used correctly by systems expecting W3C-DTF, http://www.w3.org/TR/xmlschema-2/#dateTime or RFC3339, covers the same value-range as RFC2822 and forces the use of UTC which simplifies coding and reduces ambiguity. I'd recommend we make the "T" and "Z" something that MUST be send upper-case, but SHOULD be accepted in either-case. It can be expressed as the following XML Schema: The pattern is looser than the BNF above for simplicity sake, when combined with the fact that it must also be valid as an xs:dateTime it would be equivalent to that BNF. From owner-ietf-message-xml Fri Feb 7 04:32:41 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17CWft25148 for ietf-message-xml-bks; Fri, 7 Feb 2003 04:32:41 -0800 (PST) Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by above.proper.com (8.11.6/8.11.3) with SMTP id h17CWed25144 for ; Fri, 7 Feb 2003 04:32:40 -0800 (PST) Received: (qmail 15601 messnum 601551 invoked from network[213.190.156.86/quake.spin.ie]); 7 Feb 2003 12:32:34 -0000 Received: from quake.spin.ie (HELO cerridwen) (213.190.156.86) by mail00.svc.cra.dublin.eircom.net (qp 15601) with SMTP; 7 Feb 2003 12:32:34 -0000 From: "Jon Hanna" To: Subject: RE: XML message format draft Date: Fri, 7 Feb 2003 12:33:43 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5.1.0.14.2.20030206172630.00a0e920@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > My own preference for a urn: form here is a reflection that this > specification is intended to closely reflect some IETF > specifications, and > the URIs used should be within IETF/IANA change-control. At the present > time, as far as I am aware, IETF/IANA are not signed up to the "cool URIs > don't change" [3] commitment needed for http: URIs to be sufficiently > stable. Further, I wish to leverage the message header registry proposal > [4] that I believe is on its way to being a BCP. URIs themselves are defined by IETF RFCs. Since the use of URIs as namespace names is as opaque identifiers they are immutable for that purpose whatever form they take. Documents obtainable by dereferencing URIs should not be essential to the operation of the namespace, as useful as they may be. Hence there is not a absolute requirement that the URIs be cool in anyway other than they don't change as opaque identifiers. While a change to whether or not the URI can be dereferenced may be an inconvenience, it wouldn't break the format itself. Hence I don't think that is a reason for avoiding HTTP URLs. From owner-ietf-message-xml Fri Feb 7 07:01:53 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17F1rm04862 for ietf-message-xml-bks; Fri, 7 Feb 2003 07:01:53 -0800 (PST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17F1qd04858 for ; Fri, 7 Feb 2003 07:01:52 -0800 (PST) Received: from GK-VAIO.ninebynine.org (IDENT:root@localhost [127.0.0.1]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id HAA17270; Fri, 7 Feb 2003 07:01:22 -0800 Message-Id: <5.1.0.14.2.20030207150043.00a3bb70@127.0.0.1> X-Sender: gk-lists@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Feb 2003 15:07:57 +0000 To: Chris Croome From: Graham Klyne Subject: Re: XML message format draft Cc: ietf-message-xml@imc.org In-Reply-To: <20030206224823.GB20949@webarchitects.co.uk> References: <5.1.0.14.2.20030206172630.00a0e920@127.0.0.1> <5.1.0.14.2.20030120191559.00a2c190@127.0.0.1> <5.1.0.14.2.20020911214829.0399e630@127.0.0.1> <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <1031329936.12734.3951.camel@dirk> <3D78DDCD.60000@textuality.com> <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <5.1.0.14.2.20020911214829.0399e630@127.0.0.1> <5.1.0.14.2.20030120191559.00a2c190@127.0.0.1> <5.1.0.14.2.20030206172630.00a0e920@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Chris, At 10:48 PM 2/6/03 +0000, Chris Croome wrote: > > My own preference for a urn: form here is a reflection that this > > specification is intended to closely reflect some IETF > > specifications, and the URIs used should be within IETF/IANA > > change-control. > >Fair enough, the only reason I could think of to use a http:// URI >would be in order to have a useful document at the URI address -- >but in the absence of any agreement on this there is no good reason >not to use a urn:. I don't mean to disregard the value of a useful document, even in the absence of agreement. > > And also, a quick comparison with the RSS module. while the broad > > approach is similar, there are a number of differences in the way > > some details are handled: > > Also, within this framework, I have defined an XML/RDF structure > > to represent email group addresses. > >Sorry I don't understand this, by email group do you mean email >list? I mean email addresses like this: groupname: local1@domain1, local2@domain2 ; or just: groupname: ; (This is an often-overlooked feature of RFC 2822.) > > I'm sure there are other differences. I'm mainly trying to give a > > sense of the key differences in approach so we can explore them. > >One other issue that has come up for me is the situation when XML is >being used to generate plain text emails -- using case sensitive >element names saves writing code to generate headers with the >correct case from all lower case XML elements -- what do you think >about this? Er, I don't see the problem here. RFC2822 header field names are case insensitive, so the corresponding XML element names could be used as-is. Going the other way, I think some case normalization is required. Am I missing something? (I can't remember offhand if that's in the current spec. If there are other message formats with case sensitive header field names, then I think they should be used verbatim in all cases.) #g ------------------- Graham Klyne From owner-ietf-message-xml Fri Feb 7 07:34:56 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17FYuw05874 for ietf-message-xml-bks; Fri, 7 Feb 2003 07:34:56 -0800 (PST) Received: from mail.webarchitects.co.uk (owl.webarchitects.co.uk [195.10.230.119]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17FYtd05870 for ; Fri, 7 Feb 2003 07:34:55 -0800 (PST) Received: by mail.webarchitects.co.uk (Postfix, from userid 501) id D3C4C2B145; Fri, 7 Feb 2003 15:34:50 +0000 (GMT) Date: Fri, 7 Feb 2003 15:34:50 +0000 From: Chris Croome To: Graham Klyne Cc: ietf-message-xml@imc.org Subject: Re: XML message format draft Message-ID: <20030207153450.GD26310@webarchitects.co.uk> References: <5.1.0.14.2.20030120191559.00a2c190@127.0.0.1> <5.1.0.14.2.20020911214829.0399e630@127.0.0.1> <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <1031329936.12734.3951.camel@dirk> <3D78DDCD.60000@textuality.com> <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <5.1.0.14.2.20020911214829.0399e630@127.0.0.1> <5.1.0.14.2.20030120191559.00a2c190@127.0.0.1> <5.1.0.14.2.20030206172630.00a0e920@127.0.0.1> <5.1.0.14.2.20030207150043.00a3bb70@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030207150043.00a3bb70@127.0.0.1> User-Agent: Mutt/1.4i x-editor: VIM - Vi IMproved 5.7 - http://www.vim.org/ x-os: Linux 2.2.20-2tr i686 x-uptime: 2:51pm up 147 days, 4:40, 3 users, load average: 0.36, 0.17, 0.10 x-pgp-key: http://chris.croome.net/pgp.html x-pgp-keyid: 0x8BB2DE91 Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi On Fri 07-Feb-2003 at 03:07:57PM +0000, Graham Klyne wrote: > > I mean email addresses like this: > > groupname: local1@domain1, local2@domain2 ; > > (This is an often-overlooked feature of RFC 2822.) Oh, OK, I think I need to do some background reading! > >One other issue that has come up for me is the situation when XML > >is being used to generate plain text emails -- using case > >sensitive element names saves writing code to generate headers > >with the correct case from all lower case XML elements -- what do > >you think about this? > > Er, I don't see the problem here. RFC2822 header field names are > case insensitive, so the corresponding XML element names could be > used as-is. But is is good practive to produce email headers that are lower case? This issue has come up is when we have wanted to produce XML templates for generating email, for example: newsletter@mkdoc.com fred.flintstone@rocks.com Here the element names are in the case thet we want the email headers to be generated in. We could use all lowercase element names but then we would want to write some code to 'correct' the case of the headers just because no one else generates lower case headers (have you ever seen any?). Chris PS I did try lowercasing all the headers in this email but my MUA (mutt) corrected them for me! -- Chris Croome web design http://www.webarchitects.co.uk/ web content management http://mkdoc.com/ everything else http://chris.croome.net/ From owner-ietf-message-xml Fri Feb 7 07:59:25 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17FxPX07932 for ietf-message-xml-bks; Fri, 7 Feb 2003 07:59:25 -0800 (PST) Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by above.proper.com (8.11.6/8.11.3) with SMTP id h17FxNd07927 for ; Fri, 7 Feb 2003 07:59:23 -0800 (PST) Received: (qmail 55751 messnum 436572 invoked from network[213.190.156.86/quake.spin.ie]); 7 Feb 2003 15:59:18 -0000 Received: from quake.spin.ie (HELO cerridwen) (213.190.156.86) by mail05.svc.cra.dublin.eircom.net (qp 55751) with SMTP; 7 Feb 2003 15:59:18 -0000 From: "Jon Hanna" To: Subject: RE: XML message format draft Date: Fri, 7 Feb 2003 16:00:26 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20030206224823.GB20949@webarchitects.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > One other issue that has come up for me is the situation when XML is > being used to generate plain text emails -- using case sensitive > element names saves writing code to generate headers with the > correct case from all lower case XML elements -- what do you think > about this? At a glance at least (haven't nit-picked my way through yet) the case-style matches the common RDF mnemonic. Without a clear reason to do otherwise I would favour retaining this. From owner-ietf-message-xml Fri Feb 7 08:23:31 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17GNVG10109 for ietf-message-xml-bks; Fri, 7 Feb 2003 08:23:31 -0800 (PST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17GNUd10103 for ; Fri, 7 Feb 2003 08:23:30 -0800 (PST) Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA21443 for ; Fri, 7 Feb 2003 08:23:16 -0800 X-Envelope-To: Received: from above.proper.com (mail.proper.com [208.184.76.45]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id MAA07627 for ; Thu, 6 Feb 2003 12:28:56 -0800 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16KSgs29829 for ietf-message-xml-bks; Thu, 6 Feb 2003 12:28:42 -0800 (PST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16KSfd29825 for ; Thu, 6 Feb 2003 12:28:41 -0800 (PST) Received: from GK-VAIO.NineByNine.org (IDENT:root@localhost [127.0.0.1]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id MAA07523 for ; Thu, 6 Feb 2003 12:28:26 -0800 Message-Id: <5.1.0.14.2.20030206182119.00a11420@127.0.0.1> X-Sender: gk@127.0.0.1 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Feb 2003 18:24:55 +0000 To: XML message format From: Graham Klyne Subject: Haystack? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Archive: List-Unsubscribe: List-ID: X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Status: Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It's been suggested to me that MIT's haystack project [1] may have some experience relevant to this message format work. I've taken a quick look, and it seems to me that the focus of Haystack is higher level. Apart from mentioning that it uses RDF, I can find no description or commentary about the email format used. Does anyone on the list know of any Haystack experience that might be relevant? #g -- [1] http://haystack.lcs.mit.edu/ ------------------- Graham Klyne From owner-ietf-message-xml Fri Feb 7 09:38:24 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17HcOF14887 for ietf-message-xml-bks; Fri, 7 Feb 2003 09:38:24 -0800 (PST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17HcNd14882 for ; Fri, 7 Feb 2003 09:38:23 -0800 (PST) Received: from GK-VAIO.ninebynine.org (IDENT:root@localhost [127.0.0.1]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA25757; Fri, 7 Feb 2003 09:38:04 -0800 Message-Id: <5.1.0.14.2.20030207165513.03abb1d0@127.0.0.1> X-Sender: gk-bulk@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Feb 2003 17:06:11 +0000 To: "Jon Hanna" From: Graham Klyne Subject: RE: XML message format draft Cc: In-Reply-To: References: <5.1.0.14.2.20030206172630.00a0e920@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:33 PM 2/7/03 +0000, Jon Hanna wrote: > > My own preference for a urn: form here is a reflection that this > > specification is intended to closely reflect some IETF > > specifications, and > > the URIs used should be within IETF/IANA change-control. At the present > > time, as far as I am aware, IETF/IANA are not signed up to the "cool URIs > > don't change" [3] commitment needed for http: URIs to be sufficiently > > stable. Further, I wish to leverage the message header registry proposal > > [4] that I believe is on its way to being a BCP. > >URIs themselves are defined by IETF RFCs. Since the use of URIs as namespace >names is as opaque identifiers they are immutable for that purpose whatever >form they take. I think there's an additional requirement... that the URIs be traceably related to the corresponding IETF specifications (e.g. RFC2822, etc.). Currently, I feel that's easier to achieve with urn: forms, by way of the IANA registry for URN namespaces. >Documents obtainable by dereferencing URIs should not be essential to the >operation of the namespace, as useful as they may be. Hence there is not a >absolute requirement that the URIs be cool in anyway other than they don't >change as opaque identifiers. While a change to whether or not the URI can >be dereferenced may be an inconvenience, it wouldn't break the format >itself. Hence I don't think that is a reason for avoiding HTTP URLs. I agree fully with the first sentence, and partly with the rest. But if the URI isn't clearly bound to the specification element it identifies, there's a possibility (maybe very remote) that it will end up being used to reference a document with completely different purpose. I think that is a potent reason to avoid "uncool" URIs. Therefore, I see three goals if http URIs are to be used for IETF header field identifiers: (a) the administrator of the domain concerned MUST approve use of the URIs concerned for this purpose. (b) the administrator of the domain concerned MUST be committed to maintaining the URIs stable. (c) the domain used SHOULD be under IETF/IANA administrative control. #g ------------------- Graham Klyne From owner-ietf-message-xml Fri Feb 7 09:38:19 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17HcJo14875 for ietf-message-xml-bks; Fri, 7 Feb 2003 09:38:19 -0800 (PST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17HcId14871 for ; Fri, 7 Feb 2003 09:38:18 -0800 (PST) Received: from GK-VAIO.ninebynine.org (IDENT:root@localhost [127.0.0.1]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA25750; Fri, 7 Feb 2003 09:38:00 -0800 Message-Id: <5.1.0.14.2.20030207164359.03ab9c80@127.0.0.1> X-Sender: gk-bulk@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Feb 2003 16:54:23 +0000 To: "Jon Hanna" From: Graham Klyne Subject: RE: XML message format draft Cc: In-Reply-To: References: <5.1.0.14.2.20030206181008.00a1ed90@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:45 AM 2/7/03 +0000, Jon Hanna wrote: > > As for time format, I'd like to move to a generic ISO8601-based form per > > RFC 3339 [1] or XML schema [2]. > > > > #g > > -- > > > > [1] http://www.ietf.org/rfc/rfc3339.txt > > > > [2] http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime > >Agreed. > >I would suggest that we define a datetime which: > >1. Is a subset of those allowed in the two works cited above, and also in >NOTE-datetime (commonly referred to as >W3CDTF), and as such also compatible with Dublin Core's W3CDTF (which is >just a reuse of the former, with a DC-supplied URI). I think RFC 3339 satisfies that goal, when used with one additional restriction: the letters T and Z MUST be in uppercase. (Note: RFC3339 and the W3CTDF were both derived from the same original.) >2. Had the same range and precision as that used in RFC2822. You mean not including sub-second resolution? Hmmm... maybe. Treating a Time element as corresponding exactly to RFC2822 then that makes sense. Then we'd have to use a different element if we really wanted to express times with sub-second resolution. I'm undecided. >3. Was always expressed in terms of UTC/GMT. Er, in a sense, that requirement conflicts with your 2. RFC2822 explicitly allows (and, I think, encourages) use of non-UTC timezones. RFC3339 allows just Z or a numeric offset, so normalizing to UTC should always be easy to do. >As such we would have a datetime format expressed as the following ABNF: [...] I'm reluctant to create yet another definition of date-time format. The work Chirs Newman and I did on RFC3339 was intended to avoid just that outcome. If some changes are really needed, I think it would be better to specify #g ------------------- Graham Klyne From owner-ietf-message-xml Fri Feb 7 10:53:56 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17IruB19316 for ietf-message-xml-bks; Fri, 7 Feb 2003 10:53:56 -0800 (PST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17Irtd19309 for ; Fri, 7 Feb 2003 10:53:55 -0800 (PST) Received: from GK-VAIO.ninebynine.org (IDENT:root@localhost [127.0.0.1]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA30000; Fri, 7 Feb 2003 10:53:34 -0800 Message-Id: <5.1.0.14.2.20030207175215.00a4ade0@127.0.0.1> X-Sender: gk-lists@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Feb 2003 18:02:35 +0000 To: Chris Croome From: Graham Klyne Subject: Re: XML message format draft Cc: ietf-message-xml@imc.org In-Reply-To: <20030207153450.GD26310@webarchitects.co.uk> References: <5.1.0.14.2.20030207150043.00a3bb70@127.0.0.1> <5.1.0.14.2.20030120191559.00a2c190@127.0.0.1> <5.1.0.14.2.20020911214829.0399e630@127.0.0.1> <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <1031329936.12734.3951.camel@dirk> <3D78DDCD.60000@textuality.com> <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <5.1.0.14.2.20020911214829.0399e630@127.0.0.1> <5.1.0.14.2.20030120191559.00a2c190@127.0.0.1> <5.1.0.14.2.20030206172630.00a0e920@127.0.0.1> <5.1.0.14.2.20030207150043.00a3bb70@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Chris, I think I now have some idea of your concern. "But is it good practice to produce email headers that are lower case?" I don't think it's a *bad* practice. Maybe the question to ask is: "Are there any known problems caused by sending emails with lower case email headers?". Also, when I mentioned case normalization, lowercase is just one option (though the most likely option). This is an issue to which I've not previously given adequate thought. I see two choices: (a) adopt some case-normalized form (e.g. all lowercase) for all header names in XML, and copy them as-is into RFC2822 messages. This has the advantage of being pretty simple to implement in a completely generic fashion. But note the question above. (b) adopt a standard spelling w.r.t. upper/lower case for all headers. This may be more stylish, but I think it raises problems in the scenarios you mention, particularly when trying to map from RFC2822 messages to XML in a generic fashion: what to do about previously unknown header field names? This looks rather problematic to me. Any other ideas? #g -- At 03:34 PM 2/7/03 +0000, Chris Croome wrote: > > >One other issue that has come up for me is the situation when XML > > >is being used to generate plain text emails -- using case > > >sensitive element names saves writing code to generate headers > > >with the correct case from all lower case XML elements -- what do > > >you think about this? > > > > Er, I don't see the problem here. RFC2822 header field names are > > case insensitive, so the corresponding XML element names could be > > used as-is. > >But is is good practive to produce email headers that are lower >case? > >This issue has come up is when we have wanted to produce XML >templates for generating email, for example: > > petal:define="config here/config --flo.plugin.Account" > petal:contents="config/mail_from">newsletter@mkdoc.com > > petal:contents="here/ticket/email">fred.flintstone@rocks.com > >Here the element names are in the case thet we want the email >headers to be generated in. We could use all lowercase element names >but then we would want to write some code to 'correct' the case of >the headers just because no one else generates lower case headers >(have you ever seen any?). > >Chris > >PS I did try lowercasing all the headers in this email but my MUA >(mutt) corrected them for me! ------------------- Graham Klyne From owner-ietf-message-xml Fri Feb 7 10:53:53 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17Irrm19298 for ietf-message-xml-bks; Fri, 7 Feb 2003 10:53:53 -0800 (PST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17Irqd19291 for ; Fri, 7 Feb 2003 10:53:52 -0800 (PST) Received: from GK-VAIO.ninebynine.org (IDENT:root@localhost [127.0.0.1]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA29998; Fri, 7 Feb 2003 10:53:33 -0800 Message-Id: <5.1.0.14.2.20030207185352.00a69ec0@127.0.0.1> X-Sender: gk-bulk@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Feb 2003 18:54:11 +0000 To: "Jon Hanna" From: Graham Klyne Subject: RE: XML message format draft Cc: In-Reply-To: References: <20030206224823.GB20949@webarchitects.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 04:00 PM 2/7/03 +0000, Jon Hanna wrote: > > One other issue that has come up for me is the situation when XML is > > being used to generate plain text emails -- using case sensitive > > element names saves writing code to generate headers with the > > correct case from all lower case XML elements -- what do you think > > about this? > >At a glance at least (haven't nit-picked my way through yet) the case-style >matches the common RDF mnemonic. Without a clear reason to do otherwise I >would favour retaining this. Yes, me too. #g ------------------- Graham Klyne From owner-ietf-message-xml Fri Feb 7 13:27:35 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17LRZ324683 for ietf-message-xml-bks; Fri, 7 Feb 2003 13:27:35 -0800 (PST) Received: from mail.webarchitects.co.uk (owl.webarchitects.co.uk [195.10.230.119]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17LRXd24678 for ; Fri, 7 Feb 2003 13:27:34 -0800 (PST) Received: by mail.webarchitects.co.uk (Postfix, from userid 501) id 1D9072B144; Fri, 7 Feb 2003 21:27:31 +0000 (GMT) Date: Fri, 7 Feb 2003 21:27:31 +0000 From: Chris Croome To: Graham Klyne Cc: ietf-message-xml@imc.org Subject: Re: XML message format draft Message-ID: <20030207212731.GB28122@webarchitects.co.uk> References: <5.1.0.14.2.20020911214829.0399e630@127.0.0.1> <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <1031329936.12734.3951.camel@dirk> <3D78DDCD.60000@textuality.com> <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <5.1.0.14.2.20020911214829.0399e630@127.0.0.1> <5.1.0.14.2.20030120191559.00a2c190@127.0.0.1> <5.1.0.14.2.20030206172630.00a0e920@127.0.0.1> <5.1.0.14.2.20030207150043.00a3bb70@127.0.0.1> <5.1.0.14.2.20030207175215.00a4ade0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030207175215.00a4ade0@127.0.0.1> User-Agent: Mutt/1.4i X-Editor: VIM - Vi IMproved 5.7 - http://www.vim.org/ X-OS: Linux 2.2.20-2tr i686 X-Uptime: 8:11pm up 147 days, 10:00, 4 users, load average: 0.08, 0.07, 0.07 X-PGP-Key: http://chris.croome.net/pgp.html X-PGP-KeyID: 0x8BB2DE91 Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Graham On Fri 07-Feb-2003 at 06:02:35PM +0000, Graham Klyne wrote: > > "But is it good practice to produce email headers that are lower case?" > > I don't think it's a *bad* practice. OK, but it's so uncommon that it doesn't seem to be a sensible thing to do... > Maybe the question to ask is: "Are there any known problems caused > by sending emails with lower case email headers?". Good question. I don't know. However I do know that there are a _lot_ of broken mail servers and mail clients out there and I can't think of a good reason to risk upsetting other software when producing software that sends out email. Sending things out in a case sensitive way (using the norms) and accepting either seems the best thing to do. > Also, when I mentioned case normalization, lowercase is just one > option (though the most likely option). True. > This is an issue to which I've not previously given adequate > thought. I see two choices: > > (a) adopt some case-normalized form (e.g. all lowercase) for all > header names in XML, and copy them as-is into RFC2822 messages. > This has the advantage of being pretty simple to implement in a > completely generic fashion. But note the question above. > > (b) adopt a standard spelling w.r.t. upper/lower case for all > headers. This may be more stylish, but I think it raises problems > in the scenarios you mention, particularly when trying to map from > RFC2822 messages to XML in a generic fashion: what to do about > previously unknown header field names? This looks rather > problematic to me. I'm not sure I really understand these two options, however the way I see it is that when producing plain text mail to put over the net it's probably best to stick to case conventions. When this email is being produced from a XML templating system one can match the case in the XML or do something with regular expressions (like this Perl module does: http://search.cpan.org/author/NWIGER/Text-Header-1.03/Header.pm Currently, due to being lazy we are doing the former, but using one extra Perl module isn't a big deal so I'm easy on this issue. Chris -- Chris Croome web design http://www.webarchitects.co.uk/ web content management http://mkdoc.com/ everything else http://chris.croome.net/ From owner-ietf-message-xml Fri Feb 7 13:35:19 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17LZJD24904 for ietf-message-xml-bks; Fri, 7 Feb 2003 13:35:19 -0800 (PST) Received: from mail.webarchitects.co.uk (owl.webarchitects.co.uk [195.10.230.119]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17LZId24900 for ; Fri, 7 Feb 2003 13:35:18 -0800 (PST) Received: by mail.webarchitects.co.uk (Postfix, from userid 501) id 3F6BE2B149; Fri, 7 Feb 2003 21:35:15 +0000 (GMT) Date: Fri, 7 Feb 2003 21:35:15 +0000 From: Chris Croome To: Graham Klyne Cc: ietf-message-xml@imc.org Subject: Re: XML message format draft Message-ID: <20030207213515.GC28122@webarchitects.co.uk> References: <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <1031329936.12734.3951.camel@dirk> <3D78DDCD.60000@textuality.com> <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <5.1.0.14.2.20020911214829.0399e630@127.0.0.1> <5.1.0.14.2.20030120191559.00a2c190@127.0.0.1> <5.1.0.14.2.20030206172630.00a0e920@127.0.0.1> <5.1.0.14.2.20030207150043.00a3bb70@127.0.0.1> <5.1.0.14.2.20030207175215.00a4ade0@127.0.0.1> <20030207212731.GB28122@webarchitects.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030207212731.GB28122@webarchitects.co.uk> User-Agent: Mutt/1.4i X-Editor: VIM - Vi IMproved 5.7 - http://www.vim.org/ X-OS: Linux 2.2.20-2tr i686 X-Uptime: 8:11pm up 147 days, 10:00, 4 users, load average: 0.08, 0.07, 0.07 X-PGP-Key: http://chris.croome.net/pgp.html X-PGP-KeyID: 0x8BB2DE91 Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi On Fri 07-Feb-2003 at 09:27:31PM +0000, Chris Croome wrote: > > it's probably best to stick to case conventions. When this email > is being produced from a XML templating system one can match the > case in the XML Like this Perl module does: http://search.cpan.org/author/MARKOV/MailTools-1.58/Mail/Header.pm > or do something with regular expressions (like this Perl module > does: > > http://search.cpan.org/author/NWIGER/Text-Header-1.03/Header.pm Two concrete option of the two different ways to deal with case in email headers (now I expect someone will point out that they are both wrong!). Chris -- Chris Croome web design http://www.webarchitects.co.uk/ web content management http://mkdoc.com/ everything else http://chris.croome.net/ From owner-ietf-message-xml Fri Feb 7 14:54:27 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17MsRD27360 for ietf-message-xml-bks; Fri, 7 Feb 2003 14:54:27 -0800 (PST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17MsRd27356 for ; Fri, 7 Feb 2003 14:54:27 -0800 (PST) Received: from bbprime.brandenburg.com (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id OAA09422; Fri, 7 Feb 2003 14:54:11 -0800 Date: Fri, 7 Feb 2003 12:12:36 -0800 From: Dave Crocker X-Mailer: The Bat! (v1.63 Beta/4) Personal Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <9154495049.20030207121236@brandenburg.com> To: Graham Klyne CC: "Jon Hanna" , ietf-message-xml@imc.org Subject: Re: XML message format draft In-Reply-To: <5.1.0.14.2.20030207164359.03ab9c80@127.0.0.1> References: <5.1.0.14.2.20030206181008.00a1ed90@127.0.0.1> <5.1.0.14.2.20030207164359.03ab9c80@127.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Graham, Friday, February 7, 2003, 8:54:23 AM, you wrote: >>3. Was always expressed in terms of UTC/GMT. GK> Er, in a sense, that requirement conflicts with your 2. RFC2822 GK> explicitly allows (and, I think, encourages) use of non-UTC GK> timezones. RFC3339 allows just Z or a numeric offset, so normalizing to GK> UTC should always be easy to do. In addition, knowing the timezone of origin can be very helpful to the reader. did the author write the note at the beginning of their day? the end? the middle of the night? d/ -- Dave Brandenburg InternetWorking t +1.408.246.8253; f +1.408.850.1850 From owner-ietf-message-xml Tue Feb 11 06:25:01 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BEP1823910 for ietf-message-xml-bks; Tue, 11 Feb 2003 06:25:01 -0800 (PST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BEP0d23904 for ; Tue, 11 Feb 2003 06:25:00 -0800 (PST) Received: from GK-VAIO.ninebynine.org (IDENT:root@localhost [127.0.0.1]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id GAA23028; Tue, 11 Feb 2003 06:24:33 -0800 Message-Id: <5.1.0.14.2.20030210170054.0385dec0@127.0.0.1> X-Sender: gk-lists@127.0.0.1 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 10 Feb 2003 17:18:06 +0000 To: Chris Croome From: Graham Klyne Subject: Header field name case in XML Cc: ietf-message-xml@imc.org In-Reply-To: <20030207212731.GB28122@webarchitects.co.uk> References: <5.1.0.14.2.20030207175215.00a4ade0@127.0.0.1> <5.1.0.14.2.20020911214829.0399e630@127.0.0.1> <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <1031329936.12734.3951.camel@dirk> <3D78DDCD.60000@textuality.com> <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <5.1.0.14.2.20020911214829.0399e630@127.0.0.1> <5.1.0.14.2.20030120191559.00a2c190@127.0.0.1> <5.1.0.14.2.20030206172630.00a0e920@127.0.0.1> <5.1.0.14.2.20030207150043.00a3bb70@127.0.0.1> <5.1.0.14.2.20030207175215.00a4ade0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 09:27 PM 2/7/03 +0000, Chris Croome wrote: >Hi Graham > >On Fri 07-Feb-2003 at 06:02:35PM +0000, Graham Klyne wrote: > > > > "But is it good practice to produce email headers that are lower case?" > > > > I don't think it's a *bad* practice. > >OK, but it's so uncommon that it doesn't seem to be a sensible thing >to do... > > > Maybe the question to ask is: "Are there any known problems caused > > by sending emails with lower case email headers?". > >Good question. I don't know. However I do know that there are a >_lot_ of broken mail servers and mail clients out there and I can't >think of a good reason to risk upsetting other software when >producing software that sends out email. Sending things out in a >case sensitive way (using the norms) and accepting either seems the >best thing to do. Since I posted that, I asked on IETF-822 [1] which has some folks to have *real* experience with *real* email, and my take on the tone of the responses was that there have been some rare examples of such problems, but not enough that we should be concerned about. [1] http://www.imc.org/ietf-822/mail-archive/msg03094.html > > This is an issue to which I've not previously given adequate > > thought. I see two choices: > > > > (a) adopt some case-normalized form (e.g. all lowercase) for all > > header names in XML, and copy them as-is into RFC2822 messages. > > This has the advantage of being pretty simple to implement in a > > completely generic fashion. But note the question above. > > > > (b) adopt a standard spelling w.r.t. upper/lower case for all > > headers. This may be more stylish, but I think it raises problems > > in the scenarios you mention, particularly when trying to map from > > RFC2822 messages to XML in a generic fashion: what to do about > > previously unknown header field names? This looks rather > > problematic to me. > >I'm not sure I really understand these two options, however the way I'll try and explain by example. I think we really need to understand each other here: If we opt for all-lower-case, (a) would have us use: ... ... ... ... (Another option might be to capitalize the first letter, but the result is still different from what follows...) The "standard spelling" approach (b) would have the xml use, say: ... ... ... ... etc. In this case, one cannot easily construct the correct element name from a given case-inconsiderate [*] input, such as a message containing the first form of input. [*] by which I mean an RFC2822 message that uses, as it is permitted to do, something other than the "conventional" case mixture for header field names. >I see it is that when producing plain text mail to put over the net >it's probably best to stick to case conventions. When this email is >being produced from a XML templating system one can match the case >in the XML or do something with regular expressions (like this Perl module >does: > > http://search.cpan.org/author/NWIGER/Text-Header-1.03/Header.pm > >Currently, due to being lazy we are doing the former, but using one >extra Perl module isn't a big deal so I'm easy on this issue. If it were just a case of one extra Perl module, I might agree. But it's more than that that's needed: given any valid email message (which *may* have header field names in all-lowercase, or all-uppercase, or anywhere between), it would be necessary to know explicitly about each header field used in order to construct the "conventional" spelling. (Ironically, by following this path, I think we'd be in danger of causing something like the very potential problem you indicate as reason to not "just use lowercase", because XML-based software could be tripped up by emails that don't use standard case conventions.) ... OK, here's a suggestion that partially addresses your concerns: (1) the XML format always uses lower case form of header field names in element names. Therefore, when mapping from RFC2822->XML, all field names are converted to lowercase. (2) software that generates RFC2822 from the XML creates "conventional case" output for those header fields for which it knows the conventional casing. (3) software that generates RFC2822 from the XML creates all-lower-case output for any other header field names. I note that items (2) and (3) are not within the scope of the XML message format specification. #g ------------------- Graham Klyne From owner-ietf-message-xml Tue Feb 11 06:24:55 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BEOt223885 for ietf-message-xml-bks; Tue, 11 Feb 2003 06:24:55 -0800 (PST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BEOsd23879 for ; Tue, 11 Feb 2003 06:24:54 -0800 (PST) Received: from GK-VAIO.NineByNine.org (IDENT:root@localhost [127.0.0.1]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id GAA23027 for ; Tue, 11 Feb 2003 06:24:32 -0800 Message-Id: <5.1.0.14.2.20030211142622.00a20780@127.0.0.1> X-Sender: gk@127.0.0.1 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Feb 2003 14:36:03 +0000 To: XML message format From: Graham Klyne Subject: Thinking about the next revision Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, In various discussions leading to formation of this discussion group, a number of points have been raised regarding the next revision of the XML message format [1]. In this message, I'm starting the process of bringing them together for discussion. If anyone has any other ideas about revisions they'd like to see, please chime in now. 1. Move closer to RDF/RSS - make more explicit use of some RDF structures (e.g. notably rdf:Resource ?). 2. Choice of namespace URI - I think the current consensus can at least tolerate the current URN approach. 3. Case conventions for XML elements (see separate message). 4. Prepare XML schema. 5. Prepare RDF schema. These issues are noted in the current document revision [1]: [[ Appendix G: Outstanding issues o After lying fallow for some time, a complete review is needed to take account of more recent thinking and ideas. Such review is planned take account of at least the following points. o Convert document source to XML2RFC format o Review for usability with RSS. o Review for ID nits conformance o Review namespace URIs. o Review MIME type name. (Message/XML? Application/Message+XML?) o Allow more flexible use of RDF syntax to reduce verbosity (but increase number of different ways of expressing some constructs in XML; e.g. adrs and name attributes for
)? o Clarify effect of namespaces (or not) on element attribute names. XML attributes do not follow the same default namespace rules as elements. o Define DTD, XML schema and RDF schema. o Finalize IANA considerations. ]] #g -- [1] http://www.ietf.org/internet-drafts/draft-klyne-message-xml-00.txt ------------------- Graham Klyne From owner-ietf-message-xml Tue Feb 11 06:44:29 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BEiTA26317 for ietf-message-xml-bks; Tue, 11 Feb 2003 06:44:29 -0800 (PST) Received: from mail.webarchitects.co.uk (owl.webarchitects.co.uk [195.10.230.119]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BEiSd26312 for ; Tue, 11 Feb 2003 06:44:28 -0800 (PST) Received: by mail.webarchitects.co.uk (Postfix, from userid 501) id 0E6D52B122; Tue, 11 Feb 2003 14:44:20 +0000 (GMT) Date: Tue, 11 Feb 2003 14:44:20 +0000 From: Chris Croome To: XML message format Subject: Case in Email Headers Message-ID: <20030211144420.GB21009@webarchitects.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Editor: VIM - Vi IMproved 5.7 - http://www.vim.org/ X-OS: Linux 2.2.20-2tr i686 X-Uptime: 11:30am up 151 days, 1:19, 3 users, load average: 0.13, 0.07, 0.11 X-PGP-Key: http://chris.croome.net/pgp.html X-PGP-KeyID: 0x8BB2DE91 Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi I have been talking about this with the guy I work with who runs our mail servers and basically mail servers take no notice whatsoever of headers and just use the email envelope for delivering mail. The things that might break with all lower case headers are things like people procmail scripts that look for a case sensitive match. For example, this rule I have to put mail from this list into a seperate mbox file: # ietf-message-xml :0: * ^List-ID:.* lists.ietf-message-xml Would break if the list-id header was lower case. Following is something he has written about this. Chris ----- Forwarded message from Bruno Postle ----- Date: Tue, 11 Feb 2003 11:02:03 +0000 From: Bruno Postle To: Chris Croome Subject: Re: Fwd: [chris@webarchitects.co.uk: Re: XML message format draft] On Mon 10-Feb-2003 at 01:09:58PM +0000, Chris Croome wrote: > > Can you let me have some examples of case conventions in email headers > that the two Perl modules linked to in the attached email don't cover. This is the rfc: http://www.faqs.org/rfcs/rfc2822.html 2.2. Header Fields Header fields are lines composed of a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF. A field name MUST be composed of printable US-ASCII characters (i.e., characters that have values between 33 and 126, inclusive), except colon. A field body may be composed of any US-ASCII characters, except for CR and LF. However, a field body may contain CRLF when used in header "folding" and "unfolding" as described in section 2.2.3. All field bodies MUST conform to the syntax described in sections 3 and 4 of this standard. The convention is to capitalise each word like this: Content-Transfer-Encoding: 7bit ..but there two common exceptions: MIME-Version: 1.0 Message-ID: <20030211103735.GB18894@webarchitects.co.uk> ..however the mutt developers do them like this: Mime-Version: 1.0 Message-ID: <20030211103735.GB18894@webarchitects.co.uk> All the other mixed-up-case headers are always 'X' headers, and so unimportant: exchange: X-MSMail-Priority: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 gnu-mailman: X-BeenThere: sheffcol-web@webarch.co.uk croome: X-PGP-Key: http://chris.croome.net/pgp.html X-PGP-KeyID: 0x8BB2DE91 -- Bruno ----- End forwarded message ----- -- Chris Croome web design http://www.webarchitects.co.uk/ web content management http://mkdoc.com/ everything else http://chris.croome.net/ From owner-ietf-message-xml Tue Feb 11 07:00:23 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BF0NA26797 for ietf-message-xml-bks; Tue, 11 Feb 2003 07:00:23 -0800 (PST) Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1BF0Md26792 for ; Tue, 11 Feb 2003 07:00:22 -0800 (PST) Received: (qmail 43067 messnum 456341 invoked from network[213.190.156.86/quake.spin.ie]); 11 Feb 2003 15:00:17 -0000 Received: from quake.spin.ie (HELO cerridwen) (213.190.156.86) by mail05.svc.cra.dublin.eircom.net (qp 43067) with SMTP; 11 Feb 2003 15:00:17 -0000 From: "Jon Hanna" To: Subject: RE: Header field name case in XML Date: Tue, 11 Feb 2003 15:01:38 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5.1.0.14.2.20030210170054.0385dec0@127.0.0.1> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To my mind this is a question about to what extent this format is the same as RFC2822 and to what extent it is different. RFC2822 is case-insensitive. This format cannot be. Any attempt to mirror the cases that are common practice with RFC2822 can only lead to confusion. There is nothing to stop MessageXML-2-2822 conversion normalising on some case convention (just like 2822-2-MessageXML conversion MUST). So there is little real gain from a RFC2822 compatibility perspective in any given case convention. From owner-ietf-message-xml Tue Feb 11 11:41:03 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BJf3x12441 for ietf-message-xml-bks; Tue, 11 Feb 2003 11:41:03 -0800 (PST) Received: from mail.webarchitects.co.uk (owl.webarchitects.co.uk [195.10.230.119]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BJf2d12437 for ; Tue, 11 Feb 2003 11:41:02 -0800 (PST) Received: by mail.webarchitects.co.uk (Postfix, from userid 501) id E8AB02B123; Tue, 11 Feb 2003 19:40:58 +0000 (GMT) Date: Tue, 11 Feb 2003 19:40:58 +0000 From: Chris Croome To: Graham Klyne Cc: ietf-message-xml@imc.org Subject: Re: Header field name case in XML Message-ID: <20030211194058.GA23192@webarchitects.co.uk> References: <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <1031329936.12734.3951.camel@dirk> <3D78DDCD.60000@textuality.com> <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <5.1.0.14.2.20020911214829.0399e630@127.0.0.1> <5.1.0.14.2.20030120191559.00a2c190@127.0.0.1> <5.1.0.14.2.20030206172630.00a0e920@127.0.0.1> <5.1.0.14.2.20030207150043.00a3bb70@127.0.0.1> <5.1.0.14.2.20030207175215.00a4ade0@127.0.0.1> <5.1.0.14.2.20030210170054.0385dec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030210170054.0385dec0@127.0.0.1> User-Agent: Mutt/1.4i X-Editor: VIM - Vi IMproved 5.7 - http://www.vim.org/ X-OS: Linux 2.2.20-2tr i686 X-Uptime: 7:30pm up 151 days, 9:19, 4 users, load average: 0.03, 0.01, 0.00 X-PGP-Key: http://chris.croome.net/pgp.html X-PGP-KeyID: 0x8BB2DE91 Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Graham On Mon 10-Feb-2003 at 05:18:06PM +0000, Graham Klyne wrote: > > OK, here's a suggestion that partially addresses your concerns: > > (1) the XML format always uses lower case form of header field > names in element names. Therefore, when mapping from > RFC2822->XML, all field names are converted to lowercase. > > (2) software that generates RFC2822 from the XML creates > "conventional case" output for those header fields for which it > knows the conventional casing. > > (3) software that generates RFC2822 from the XML creates > all-lower-case output for any other header field names. > > I note that items (2) and (3) are not within the scope of the XML > message format specification. Yes, this makes sense to me, I can't think of a better suggestion. Chris -- Chris Croome web design http://www.webarchitects.co.uk/ web content management http://mkdoc.com/ everything else http://chris.croome.net/ From owner-ietf-message-xml Tue Feb 11 21:11:43 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1C5Bh628108 for ietf-message-xml-bks; Tue, 11 Feb 2003 21:11:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1C5Bgd28104 for ; Tue, 11 Feb 2003 21:11:42 -0800 (PST) Received: from esunmail ([129.147.58.120]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11873 for ; Tue, 11 Feb 2003 22:11:46 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HA6008POJRME5@edgemail1.Central.Sun.COM> for ietf-message-xml@imc.org; Tue, 11 Feb 2003 22:11:46 -0700 (MST) Received: from nifty-jr.west.sun.com ([129.153.12.95]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HA6000L6JRJOP@mail.sun.net> for ietf-message-xml@imc.org; Tue, 11 Feb 2003 22:11:45 -0700 (MST) Date: Tue, 11 Feb 2003 21:11:31 -0800 From: Chris Newman Subject: Re: Header field name case in XML In-reply-to: <5.1.0.14.2.20030210170054.0385dec0@127.0.0.1> To: Graham Klyne Cc: ietf-message-xml@imc.org Message-id: <2147483647.1044997891@nifty-jr.west.sun.com> MIME-version: 1.0 X-Mailer: Mulberry/3.0.0 (Mac OS X) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Content-disposition: inline X-message-flag: Outlook: the best virus distribution system around References: <5.1.0.14.2.20030207175215.00a4ade0@127.0.0.1> <5.1.0.14.2.20020911214829.0399e630@127.0.0.1> <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <1031329936.12734.3951.camel@dirk> <3D78DDCD.60000@textuality.com> <5.1.0.14.2.20020911125038.03b1de60@127.0.0.1> <5.1.0.14.2.20020911214829.0399e630@127.0.0.1> <5.1.0.14.2.20030120191559.00a2c190@127.0.0.1> <5.1.0.14.2.20030206172630.00a0e920@127.0.0.1> <5.1.0.14.2.20030207150043.00a3bb70@127.0.0.1> <5.1.0.14.2.20030207175215.00a4ade0@127.0.0.1> <5.1.0.14.2.20030210170054.0385dec0@127.0.0.1> Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: begin quotation by Graham Klyne on 2003/2/10 17:18 +0000: > OK, here's a suggestion that partially addresses your concerns: > > (1) the XML format always uses lower case form of header field names in > element names. Therefore, when mapping from RFC2822->XML, all field > names are converted to lowercase. > > (2) software that generates RFC2822 from the XML creates "conventional > case" output for those header fields for which it knows the conventional > casing. > > (3) software that generates RFC2822 from the XML creates all-lower-case > output for any other header field names. > > I note that items (2) and (3) are not within the scope of the XML message > format specification. This sounds right to me. Since both (2) and (3) would be standards compliant, so the distinction is a quality of implementation issue, not a standards issue. - Chris From owner-ietf-message-xml Wed Feb 12 07:47:41 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CFlfV21176 for ietf-message-xml-bks; Wed, 12 Feb 2003 07:47:41 -0800 (PST) Received: from mail.webarchitects.co.uk (owl.webarchitects.co.uk [195.10.230.119]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CFldd21171 for ; Wed, 12 Feb 2003 07:47:40 -0800 (PST) Received: by mail.webarchitects.co.uk (Postfix, from userid 501) id DC2552B11A; Wed, 12 Feb 2003 15:47:17 +0000 (GMT) Date: Wed, 12 Feb 2003 15:47:17 +0000 From: Chris Croome To: XML message format Subject: Escaping things in element names, fwd: [bruno@webarchitects.co.uk: Re: Fwd: [chris@webarchitects.co.uk: Re: XML message format draft]] Message-ID: <20030212154717.GC27811@webarchitects.co.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline User-Agent: Mutt/1.4i X-_///<&;<<-\\\%: Hello World X-Editor: VIM - Vi IMproved 5.7 - http://www.vim.org/ X-OS: Linux 2.2.20-2tr i686 X-Uptime: 2:47pm up 152 days, 4:35, 3 users, load average: 0.10, 0.11, 0.09 X-PGP-Key: http://chris.croome.net/pgp.html X-PGP-KeyID: 0x8BB2DE91 Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi One the the guys I work with has pointed out that this is a valid email header: X-_///<&;<<-\\\%: Hello World I can see how to do this in XHTML for HTTP headers: I don't know how it would look as an element rather than an attribute. Chris -- Chris Croome web design http://www.webarchitects.co.uk/ web content management http://mkdoc.com/ everything else http://chris.croome.net/ --u3/rZRmxL6MmkK24 Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Delivered-To: chris@webarchitects.co.uk Received: from celery.webarchitects.co.uk (mkdoc.demon.co.uk [62.49.20.1]) by mail.webarchitects.co.uk (Postfix) with ESMTP id 611EA2B125 for ; Wed, 12 Feb 2003 15:19:56 +0000 (GMT) Received: by celery.webarchitects.co.uk (Postfix, from userid 500) id A653A396; Wed, 12 Feb 2003 15:19:55 +0000 (GMT) Date: Wed, 12 Feb 2003 15:19:55 +0000 From: Bruno Postle To: Chris Croome Subject: Re: Fwd: [chris@webarchitects.co.uk: Re: XML message format draft] Message-ID: <20030212151955.GQ19991@webarchitects.co.uk> References: <20030210130958.GA14335@webarchitects.co.uk> <20030211110202.GJ19991@webarchitects.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030211110202.GJ19991@webarchitects.co.uk> X-_///<&;<<-\\\%: Hello World X-Face: +?je=\K3V2%NTRI}N}l]g2gi?$L.3k,XskrYQ\7 Organisation: http://www.webarchitects.co.uk/ User-Agent: Mutt/1.5.3i On Tue 11-Feb-2003 at 11:02:02AM +0000, Bruno Postle wrote: > > This is the rfc: http://www.faqs.org/rfcs/rfc2822.html > > 2.2. Header Fields > > Header fields are lines composed of a field name, followed by a colon > (":"), followed by a field body, and terminated by CRLF. A field > name MUST be composed of printable US-ASCII characters (i.e., > characters that have values between 33 and 126, inclusive), except > colon. A field body may be composed of any US-ASCII characters, > except for CR and LF. However, a field body may contain CRLF when > used in header "folding" and "unfolding" as described in section > 2.2.3. All field bodies MUST conform to the syntax described in > sections 3 and 4 of this standard. That means that both of these are perfectly valid email headers: Subject: Hello World X-_///<&;<<-\\\%: Hello World -- Bruno --u3/rZRmxL6MmkK24-- From owner-ietf-message-xml Mon Feb 17 01:52:53 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1H9qre16490 for ietf-message-xml-bks; Mon, 17 Feb 2003 01:52:53 -0800 (PST) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1H9qqd16486 for ; Mon, 17 Feb 2003 01:52:52 -0800 (PST) Received: from GK-VAIO.ninebynine.org (IDENT:root@localhost [127.0.0.1]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id BAA29780; Mon, 17 Feb 2003 01:52:23 -0800 Message-Id: <5.1.0.14.2.20030216132926.033b0e00@127.0.0.1> X-Sender: gk-bulk@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 16 Feb 2003 13:56:45 +0000 To: Chris Croome From: Graham Klyne Subject: Re: Escaping things in element names Cc: XML message format In-Reply-To: <20030212154717.GC27811@webarchitects.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a point worthy of contemplation. Although the given email header is valid, I've never seen such headers used for real. So I think the question needs to be asked: is the goal here to represent every conceivable email message, or to provide a framework for representing the 99.9...% of actual emails? My intention is to use this format in conjunction with a header registry proposal [1], which I understand is pretty much on course to become BCP. In that proposal, we recommend: [[ A registered field name SHOULD conform at least to the syntax defined by RFC 2822 [4], section 3.6.8. Further, the "." character is reserved to indicate a naming sub- structure and MUST NOT be included in any registered field name. Currently, no specific sub-structure is defined; if used, any such structure MUST be defined by a standards track RFC document. Header field names may sometimes be used in URIs, URNs and/or XML. To comply with the syntactic constraints of these forms, it is recommended that characters in a registered field name are restricted to those that can be used without escaping in a URI [26] or URN [17], and that are also legal in XML [40] element names. Thus, for maximum flexibility, header field names SHOULD further be restricted to just letters, digits, hyphen ('-') and underscore ('_') characters, with the first character being a letter or underscore. ]] This does not of itself prevent use of weird header field names, but it indicates an expectation that mainstream header fields will be very much more constrained than the full range permitted by RFC 2822. I would hope that when this becomes BCP, the use of strange header field names will be further discouraged. For myself, I would be content if this format does not accommodate header fields that use unusual characters. This is a simple case that deals with most actual usage. But if others think it is important to accommodate other header field names, then I can think of some possible approaches: (I'll use this example "Hello!;_world: ...") (1) use _ as an escape character in the corresponding element name, such that _hh indicates a field name character by its hex code, and __ indicates a single _. e.g. ... (2) have a special header field name that specifies the actual name as an attribute: e.g. ... This begs a question about how to deal with different namespaces. Maybe: e.g. ... (3) I contemplated using a different namespace with implicit encoding. Messy. Any more ideas? Do we really care? #g -- [1] http://www.ietf.org/internet-drafts/draft-klyne-msghdr-registry-06.txt At 03:47 PM 2/12/03 +0000, Chris Croome wrote: >Hi > >One the the guys I work with has pointed out that this is a valid >email header: > > X-_///<&;<<-\\\%: Hello World > >I can see how to do this in XHTML for HTTP headers: > > http-equiv="X-_///<&;<<-\\\%" > content="Hello World" > /> > >I don't know how it would look as an element rather than an >attribute. > >Chris > >-- >Chris Croome >web design http://www.webarchitects.co.uk/ >web content management http://mkdoc.com/ >everything else http://chris.croome.net/ >Return-Path: >Delivered-To: chris@webarchitects.co.uk >Received: from celery.webarchitects.co.uk (mkdoc.demon.co.uk [62.49.20.1]) > by mail.webarchitects.co.uk (Postfix) with ESMTP id 611EA2B125 > for ; Wed, 12 Feb 2003 15:19:56 +0000 > (GMT) >Received: by celery.webarchitects.co.uk (Postfix, from userid 500) > id A653A396; Wed, 12 Feb 2003 15:19:55 +0000 (GMT) >Date: Wed, 12 Feb 2003 15:19:55 +0000 >From: Bruno Postle >To: Chris Croome >Subject: Re: Fwd: [chris@webarchitects.co.uk: Re: XML message format draft] >Message-ID: <20030212151955.GQ19991@webarchitects.co.uk> >References: <20030210130958.GA14335@webarchitects.co.uk> ><20030211110202.GJ19991@webarchitects.co.uk> >Mime-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline >In-Reply-To: <20030211110202.GJ19991@webarchitects.co.uk> >X-_///<&;<<-\\\%: Hello World >X-Face: +?je=\K3V2%NTRI}N}l]g2gi?$L.3k,XskrYQ\7 >Organisation: http://www.webarchitects.co.uk/ >User-Agent: Mutt/1.5.3i > >On Tue 11-Feb-2003 at 11:02:02AM +0000, Bruno Postle wrote: > > > > This is the rfc: http://www.faqs.org/rfcs/rfc2822.html > > > > 2.2. Header Fields > > > > Header fields are lines composed of a field name, followed by a colon > > (":"), followed by a field body, and terminated by CRLF. A field > > name MUST be composed of printable US-ASCII characters (i.e., > > characters that have values between 33 and 126, inclusive), except > > colon. A field body may be composed of any US-ASCII characters, > > except for CR and LF. However, a field body may contain CRLF when > > used in header "folding" and "unfolding" as described in section > > 2.2.3. All field bodies MUST conform to the syntax described in > > sections 3 and 4 of this standard. > >That means that both of these are perfectly valid email headers: > > Subject: Hello World > > X-_///<&;<<-\\\%: Hello World > >-- >Bruno ------------------- Graham Klyne From owner-ietf-message-xml Mon Feb 17 05:05:01 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1HD51R22475 for ietf-message-xml-bks; Mon, 17 Feb 2003 05:05:01 -0800 (PST) Received: from joker.webarchitects.co.uk (mkdoc.demon.co.uk [62.49.20.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HD4xd22471 for ; Mon, 17 Feb 2003 05:04:59 -0800 (PST) Received: by joker.webarchitects.co.uk (Postfix, from userid 501) id 862C8F9A5; Mon, 17 Feb 2003 13:04:57 +0000 (GMT) Date: Mon, 17 Feb 2003 13:04:57 +0000 From: Chris Croome To: XML message format Subject: Re: Escaping things in element names Message-ID: <20030217130457.GB19581@webarchitects.co.uk> Mail-Followup-To: XML message format References: <20030212154717.GC27811@webarchitects.co.uk> <5.1.0.14.2.20030216132926.033b0e00@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030216132926.033b0e00@127.0.0.1> User-Agent: Mutt/1.4i X-Uptime: 11:39am up 7 days, 1:43, 3 users, load average: 0.65, 1.61, 1.24 X-PGP-Key: http://chris.croome.net/pgp.html X-PGP-KeyID: 0x8BB2DE91 Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Graham On Sun 16-Feb-2003 at 01:56:45PM +0000, Graham Klyne wrote: > > For myself, I would be content if this format does not accommodate > header fields that use unusual characters. I agree :-) Chris -- Chris Croome web design http://www.webarchitects.co.uk/ web content management http://mkdoc.com/ everything else http://chris.croome.net/ From owner-ietf-message-xml Mon Feb 17 05:21:06 2003 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1HDL6022997 for ietf-message-xml-bks; Mon, 17 Feb 2003 05:21:06 -0800 (PST) Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1HDL4d22993 for ; Mon, 17 Feb 2003 05:21:04 -0800 (PST) Received: (qmail 33929 messnum 1107891 invoked from network[213.190.156.86/quake.spin.ie]); 17 Feb 2003 13:20:59 -0000 Received: from quake.spin.ie (HELO cerridwen) (213.190.156.86) by mail04.svc.cra.dublin.eircom.net (qp 33929) with SMTP; 17 Feb 2003 13:20:59 -0000 From: "Jon Hanna" To: Subject: RE: Escaping things in element names Date: Mon, 17 Feb 2003 13:22:40 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20030217130457.GB19581@webarchitects.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-message-xml@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There may be an argument made though for an element that encapsulates the X- headers. Since such headers are named by different (ad-hoc) decision-making processes to the standard headers, it could be useful to define an element that describes these such headers as name-value pairs. This would simplify the job of validating messages since it reduces the possibility of unknown elements being present in valid messages. This would also have the advantage of covering the entire range of possible valid headers.