[Standards-JIG] Two suggestions for JEP-0115
jhildebrand at jabber.com
Wed Jun 2 19:54:37 UTC 2004
> - I am not comfortable with having the extensions concatenated in a
> single string: would'nt it be simpler to have a list of 'ext' child
> like the following (the extra payload is not that big, and if you go
> into such details, why not having shorter namespaces ...):
> <c xmlns='http://jabber.org/protocol/caps'
> <ext value='tins'/>
> <ext value='ftrans'/>
> <ext value='xhtml'/>
The extension names DO NOT have semantic relevance. If they did, we
would have gone this direction, and the qname (tag/namespaceURI) of the
extension would have been a semantic identifier. Instead, the
extension name is a pointer to the semantic values. Space-separated
values in an attribute are more XML-like than I expected. When we
specified this JEP in DTD, the ext attribute was of type NMTOKENS
(http://www.w3.org/TR/REC-xml/#NT-Nmtokens). Schema experts: is there
a better way of mapping NMTOKENS into schema?
> - I would like to have a few lines added in the implementation notes
> about the relationships between this JEP and the Pub/Sub. I personnally
> think that JEP-0115 is good for relatively stable and of common
> capabilities, but that if a capability can change many times per IM
> session or is very specific, it should be advertized through Pub/Sub to
> avoid unneccessary presence broadcasts. One example I have in mind is
> the support of VoIP: with Jep-0115 I should advertize that 'in general'
> I have the capability do VoiP, but if I want to specify that 'right
> I can't because I am in a meeting, I should use pub/sub. This way, only
> clients that can actually do VoIP will get notified when I become
> available for voice calls.
I'm ok with putting in an implementation note like this, but I'm not
sure this example is the best, since you're likely to be sending out a
presence stanza anyway when you go into a VoIP call and come back out.
> My two cents.
> PS: I hope this JEP goes to draft soon, because I need a clean way to
> advertize capabilities between heterogeneous clients used in several
> projects for my company, and I don't want to lead client developers to
> do the job twice ...
Me, too. :)
More information about the Standards