On Thu Jun 16 09:14:41 2011, Remko Tronçon wrote:
> They're lowercase.
> The usual way that IANA names differ from other names is that
IANA always
> hash the hyphen in SHA names
Ok then, even better :)
One drawback of approach 2 and the agreement that all iana hash
names
are ok as elements is the potential clash between hash names and
element names in the namespace of the protocol using the hashes.
It's
unlikely that Jingle will ever have an element 'sha-1', but still,
theoretically ...
Hmmm... No. In the protocol, you can use a unified syntax, but in
features you wouldn't. You'd add a hashing feature, and append the
IANA names to that URI, perhaps using fragments (if they're legal in
URNs).
So Jingle FT would still use:
<hash xmlns='urn:xmpp:crypto:hash' hash='sha-1'/>
(Presumably with the hash value somewhere)
There is a risk that IANA might register a hash name which is not a
legal XML element, but the above copes with this.
I vaguely wonder whether we could use dynamically created namespaces
and/or elements, but that seems to serve little purpose except to
annoy purists.
(I'd personally enjoy the notion of a programmatically generated
schema by processing an XSLT over the XML form of the IANA registry,
but I can see the XML purists coming after me with troches and
pitchforks).
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
