Re: XML message format draft

[Chris Croome <chris@xxxxxxxxxxxxxxxxxxx>]

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                               <chris@xxxxxxxxxxxxxxxxxxx>
web design                             http://www.webarchitects.co.uk/ 
web content management                               http://mkdoc.com/   
everything else                               http://chris.croome.net/