Ashley, Thanks for the comments.
On Jan 8, 2013, at 8:21 AM, Ashley Ward <[email protected]> wrote: > Looks good - worth making the point about the transience of a label > catalog. Slight grammar error though: "Two identical catalog requests may > returned different results". I assume our editor will correct this if council approves the change. :-) > > Another thought > - if there is a chance that the catalog may change between > the client requesting it and then sending a message with a label from the > catalog, There is a chance... there's also a chance that the catalog contained labels which are not usable in the context in which the catalog was requested at the instance it was produced. Note that the 'should only' not 'shall only'. It is kind of assumed that if a user selects a label that results in a rejection that the user will eventually figure out that the label is not actually usable in the context it is being used in. This hasn't been a problem in practice. > it may be worth including some guidance for when a message is > sent with a label which is no longer acceptable (I.e. Is there a specific > error that the server should return?). The spec only says "The stanza SHOULD be discarded with, if appropriate, an error response." As XEP 258 doesn't extend error responses, there's no way to distinguish a security label rejection from the general meaning of the error response. We could look at adding a particular response that would mean "security label issue" or possibly a set of responses to indicate various possible "security label issues". From this, the client might then be able to deduce that their catalog might be out-of-date. But, personally, I think the current spec (with or without the suggested clarification) is good enough, at least for now. > > Also, I wonder if, as a future update, some kind of hint from the server > about catalog lifetime would be useful. Or this may just be a solution in > search of a problem! The lifetime of a catalog cannot generally be predicted as they can be changed on the whims of humans. I note that I am looking at ways of notifying clients that catalogs they have might be out-of-date and hence they should consider refreshing them. -- Kurt > > Cheers, > > Ash > > On 05/01/2013 03:32, "Peter Saint-Andre" <[email protected]> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Kurt Zeilenga has submitted version 1.1 of XEP-0258. This requires >> Council approval. The diff and rendered file are here: >> >> http://xmpp.org/extensions/diff/api/xep/0258/diff/1.0/vs/1.1rc1 >> >> http://xmpp.org/extensions/tmp/xep-0258-1.1.html >> >> Kurt told me he can attend the Council meeting in which this is >> discussed, if desired. >> >> Peter >> >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >> Comment: Using GnuPG with undefined - http://www.enigmail.net/ >> >> iEYEARECAAYFAlDnnsAACgkQNL8k5A2w/vygsQCfc6lCOcG9MpZTjWACa9Ecge3q >> cOsAoKDp/L5XYaX7h0wv6uUqrtMdtlp4 >> =ikhw >> -----END PGP SIGNATURE----- > >
