Justin Karneges wrote: > 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.
Done. >>> 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. Correct. >> 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. OK. >> 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. Gotcha. > 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. I have no objections to optional errors if folks will find them useful. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
