> In its place, I have tentatively added a "version" attribute...

Is it optional? :)

> Hmm... Yes, it would probably be a good idea. I'll have to work on that
> one ("infoset... *blech*").

Well, the other alternative would be to *not* require a whole document
comparison, if all you really care about are the two identity and inbox
URIs. That way the software could just store the URIs rather than worrying
about storing the entire documents, and just compare the URIs with those
in the document that comes back. Avoids the quagmire of normalisation,
canonicalisation and augmented frankinfoset comparison :)

However on the subject of normalisation... comparing two URIs is not
exactly straightforward either.

> 1) It provides a recognizable "signature"
> 2) It solves the problem of a container for multiple <notification> elements

Yes, the rna element seems to fit quite nicely. It's short, too.

> Yes, almost all of the elements allow optional content. However, they do
> not allow mixed content. They must be elements only. So instead, you could
> have:
>
> <to uri="mailto:mikeday@...">
> <ns:commonName>Michael Day</ns:commonName>
> </to>

Okay, so in RDF terms the children of the from/to/cc elements are
predicates that relate to the uri given in the attribute...

> On the other hand, if you are just suggesting the ability to put a plaintext
> name in for <from>, <to>, and <cc>, I'd be more inclined to add a "name" (or
> some such) attribute:
>
> <to uri="mailto:mikeday@..." name="Michael Day" />

Okay, now I'm torn between your proposal for infinitely extensible
metadata, RDF-style, or a more XMLish approach of allowing mixed content
and arbitrary markup inside the element, which could of course still have
metadata in attributes.

For example, this recently came up on the CSS list, when Andrew McFarland
pointed out that in his name the "c" in "Mc" should be superscript:

<to uri="..."> Andrew M^cFarland </to>

And the i18n guys are putting strong pressure on the XHTML working groups
to use element content rather than attributes for human readable text.

I suppose it needs some more thought. Perhaps there are some cooler things
that can be done with the RDF-style metadata, I don't know.

> I'm not sure I'll budge on this one. Allowing <subject> to contain markup
> feels like opening a pandora's box to me. Further, it can greatly
> complicate user interfaces to be able to support <subject>. In all of the
> other elements, additional content can be optionally ignored (see
> extension), but I think it would be hard to effectively ignore markup inside
> <subject> and still keep subject useful...

Markup can be ignored simply by taking the text and ignoring the tags, so
it needn't complicate any user interface that doesn't want to deal with
it. For example:

<subject> Hey, today is <strong>your birthday!</strong> </subject>

which may be rendered with appropriate bold fonts in a graphical user
interface, could easily be rendered "Hey, today is your birthday!" in Lynx
or Pine or a mobile phone or any other text based interface.

> That's not entirely true. A client does not know which authentication
> scheme it will need to use until the server tells it. As a result, sending
> in user:pwd according to the basic authentication scheme will do little good
> if the server is expecting to use digest authentication.

That's true! I'd forgotten that entirely, and there is no hint in the URI
of which scheme to use either.

> Having said all that, I will be uploading the new version shortly. I want
> to add some additional text and see if there are still more places that need
> cleaning up...

Great :)

Michael Day

--
YesLogic Prince prints XML!
http://yeslogic.com/prince