[Standards-JIG] XEP-0136 Thoughts and Musings
ian.paterson at clientside.co.uk
Thu Nov 9 02:13:00 UTC 2006
Olivier Goffart wrote:
> In my opinion (that i have already expressed before), the whole <message/>
> stanza should be stored.
Yes sorry my bad. I should have edited or removed this paragraph when we
added the 'save' preference attribute (see Section 3.2).
Peter Saint-Andre wrote:
> But is regulatory compliance a requirement here? Lots of implementations
> out there already do compliance but that's more of a system feature, not
> something that end users interact with (or want!) at all. I agree that
> it's a requirement for many implementations, but I don't know if it's a
> requirement for this spec. I'm not saying it's not a requirement, but we
> need to figure that out because it has a large impact on the protocol
Yes. Up until now this XEP has been targeted to users not to compliance.
I agree we need to decide if that should change. I'm persuaded that the
XEP should become dual purpose, if only because clients need to be able
to find out if a conversation is going to be logged at all (even if only
for compliance purposes) in order to negotiate the XEP-0155 'otr' field
(and XEP-0136 is currently the only mechanism it currently has for
learning about automatic server-side storage).
If this XEP becomes dual purpose (user service and compliance) then we
probably even need three storage levels (values of the 'save' attribute)
instead of two: "body" (body-only), "message" (something like what is
described in the last paragraph of Section 5.2) and "stream" (including
everything that passes over the c2s stream: presence, iq and message
wrapper elements). Server admins wanting to conserve storage space
should be allowed to switch off support for "message" and "stream".
It would also seem sensible to include different retrieval levels (to
allow a user to conserve bandwidth when browsing the archive content
using a mobile client). Note: European law gives people the right to
know what data is being kept about them by anyone.
Jean-Louis Seguineau wrote:
> The document assume that the message will only contain one body, whereas any
> message may contain several <body/> element qualified by a different
> xml:lang attribute.
Good point, multiple body elements qualified by a different xml:lang
attributes should be allowed, even when the 'save' preference attribute
is set to "body".
More information about the Standards