Rachel Blackman wrote:
> Otherwise clients may use any names with Entity Capabilites (ext > attribute). Therefore a same name could mean something different for> each active resource of my roster, which would require an IQ for each.> Why not define a standard name for each XEP like "xep-0167", or > shorter "0167" for previously used "jingle-audio"? Maybe a prefix for > private extensions?I *think* we don't need the appnames (just one more mapping for clients to remember) and can use XML namespaces instead. If not, we can always add the appnames back in. I was just trying to simplify things.You are right, from one viewpoint ;) Appnames are redundant, and would increase the registrar's workload.OK. I'm all in favor of making life easier for coders. What do others think?I think we already had this conversation on this list several months ago, and I think I'm still pretty opposed to hardcoding the meanings of ext strings into clients. If we do it, fine, I'll recode, but I dislike it now for all the same reasons I disliked it several months ago. The main one being that, like resources, I do not feel ext strings should have an implied semantic meaning. They are a code identifier, not necessarily a bit of human-readable data.Every other objection aside, I still fail to see that maintaining a hardcoded table of ext string meanings is 'easier' for me as a client dev. Doubly so since if a client defines any customized extensions I /still/ have to probe node#ext to get those *anyway*; it doesn't make it 'easier,' it just means I have to do everything I do now, but /also/ maintain a table of hardcoded ext values and use those instead of probing them. Basically, pre-filling my ext cache and allowing special case situations where the 'node' portion of 'node#ext' is meaningless. Which is doable, but does make for extra work to do 'right.'I also still feel, as before, that rewriting an existing, functional and widely deployed XEP is not the best use of our time when we still have situations such as two incompatible file transfer protocols floating around. That may be just me, though. :)
It seems that perhaps I mis-read Lauri's earlier message. There shall be no hardcoded 'ext' values in XEP-0115. End of story.There *may* be a need for registered 'app' values in XEP-0168, because perhaps it is not straightforward to know application types based on XML namespaces. E.g., is a namespace of 'urn:xmpp:jingle:audio' (or whatever is issued for XEP-0167) enough to tell you that this RAP priority refers to what earlier we were calling "jingle-audio"? I think so, but I'm willing to be argued out of that position.
Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
