On 8/16/11 3:35 AM, Dave Cridland wrote: > 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.
While we're at it we might reconsider some of the existing conditions (and not map them to official elements -- they could be extensions for particular implementations). >> > 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. Um, isn't that called a bug? >> > 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! Yeah, I wrote the proposal in a hurry. More examples are always good. /psa
