On Mon Aug 15 22:57:59 2011, Peter Saint-Andre wrote:
> 1) I don't think the new elements need to have a 1:1 mapping with
status
> codes, and the way in which the registrar considerations is
phrased
> implies this to be the case. I think we want a new registry, which
> includes "related status codes".
I think we want to define new status condition elements for each of
the
old status codes, but that we want to leave open the possibility of
defining new status conditions as well (which would be represented
only
via XML elements, not code numbers).
I think we want to have at least one status condition for any given
status code, but I don't think we need or want a 1:1 mapping.
> 2) We also need to consider that many clients only handle one
status
> code.
Which one do they handle?
I mean they will only process one in a set. Sometimes they ignore all
but the first. Sometimes they ignore all but the last.
> This means that even if there are multiple defined conditions, all
> the status codes possible may not be present. In some XEP,
somewhere, a
> discussion on which status code to pick when there are multiple
> applicable would be useful.
Right. Similar to XEP-0086.
I think more "If you want to say <room-created/><self-presence/>,
then you only want to mention status code 201", as a specific example
required for interop.
> 3) I'd like application-specific elements to be possible within
the
> defined conditions as well. This is to encourage implementors to
> specialize, rather than replace, conditions.
Section 2 states in part:
... the <conditions/> element MAY contain one or more condition
elements defined in this document (each of which MAY contain a
human-readable <text/> element and MAY contain an application-
specific condition element)
So that's already covered.
Oh, right, yes. I entirely missed both this and the structure above
it which makes this clear. Damn it, it's not in the examples!
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
