Re: XML message format draft

[Graham Klyne <GK@xxxxxxxxxxxxxx>]

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
<GK@xxxxxxxxxxxxxx>