Re: XML message format draft

[Graham Klyne <GK-lists@xxxxxxxxxxxxxx>]

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