On Jul 20, 2011, at 15:34, Dave Cridland wrote: > On Tue Jul 19 21:31:13 2011, XMPP Extensions Editor wrote: >> 1. Is this specification needed to fill gaps in the XMPP protocol stack or >> to clarify an existing protocol? > > Yes. > > >> 2. Does the specification solve the problem stated in the introduction and >> requirements? > > No. No problem is defined; see below. > > >> 3. Do you plan to implement this specification in your code? If not, why not? > > [N/A, I don't really do clients] > > >> 4. Do you have any security concerns related to this specification? > > No. > > >> 5. Is the specification accurate and clearly written? > > Not entirely. > > I'm concerned by the final rule in ยง2.3, which suggests that *any* presence > update from the contact SHOULD break the lock. I think this rule is fine; > however I think a short discussion of when to ignore this rule would be > useful.
Since I'm not aware of a situation where ignoring the rule is useful, I don't have any discussion to add (-: I can add something to the effect that "we don't know when you'd *not* want to unlock, but you're given some slight leeway to", or I change the SHOULD to MUST, or accept a contribution. > > Also, it would be useful to have a paragraph somewhere explaining what the > user experince the specification keeps talking about actually is - that is, > what the goal of the specification is. > Noted. And thank you for the feedback. - m&m
smime.p7s
Description: S/MIME cryptographic signature
