On Thursday 02 August 2007 2:20 pm, Peter Saint-Andre wrote: > Justin Karneges wrote: > > Great to see this as a XEP. > > Sure thing. BTW I can give you permissions to edit files in SVN if you > want to tweak it. :)
Yes, set me up. That would be useful for editing XEP-198 as well. > > and I don't think this is ever > > revealed. I'd suggest putting the profile of example 1 after the rules > > in section 3. > > OK. But the point of the spec is that you should not be generating such > a monstrosity. True, but as a reader I felt like the spec ended with a cliffhanger. :) And I should correct myself: we wouldn't state the profile of Example 1, rather we'd state that the Example 1 stanza is invalid. > Are RPC and SOAP part of the same profile perhaps? Nope. RPC and SOAP have similar purposes, but you would not put both in the same stanza. > So what profiles do we need? We need a bunch of individual-XEP profiles, and then the IM profile which constitutes many XEPs and an RFC. RPC is the RPC profile. SOAP is the SOAP profile. IBB is the IBB profile. x:data is the x:data profile. Pubsub is the pubsub profile. And so on. Then we'd have <body>, <subject>, chat states, etc in the IM profile. It is quite possible that the IM profile is the only "mixed" one. > > I don't know if we should consider Transmission to be a profile. Maybe > > it should be moved out of section 2. Also, it is stated, "If a message > > stanza includes only transmission elements, it can be considered in the > > transmission profile." I think in this case the message would rather be > > considered to have no profile. > > OK, I suppose that makes sense. Transmission elements are all "metadata" > (that term might be better than "trasmission" since SHIM stuff might not > be related to transmission). Yeah I'm fine with calling it metadata. > > If a client receives a message stanza with no profile (this can occur if > > the stanza is actually empty, or contains only transmission elements > > and/or unknown elements), maybe we should define a <unknown-profile> or > > such error code (or reuse a nearby code) for the client to bounce back. > > Or just eat the stanza and don't return an error. What's the point of > returning an error here? It might help for diagnostic purposes. For privacy reasons, I suppose something like this would need to be optional. > > It is possible for a client to determine conclusively that there is a > > profile conflict, if two types of differing profile elements that it > > understands happen to be present in the same message. Maybe we should > > define an error code for this as well (not-acceptable?). > > Works for me. Ditto for this one being optional. In current practice, messages with unsupported elements are not bounced. This is not really something I was setting out to fix (if there is anything to fix). I just figure errors are something cool that this XEP enables us to have if we want them. -Justin
