Re: [Standards] LAST CALL: XEP-0226 (Message Stanza Profiles)
In section 2: A message stanza SHOULD only contain profile elements that are part of the same profile. A message stanza MAY contain as many elements as necessary from the metadata profile. I suggest s/the same profile/the same standard profile/. I concur comments of others that XEP 258 security labels should be in the metadata profile. I'll document an registry update request in XEP 258's IANA Considerations and submit that request to the registrar. -- Kurt
Re: [Standards] LAST CALL: XEP-0226 (Message Stanza Profiles)
On 11/16/09 9:19 AM, Dave Cridland wrote: > On Mon Nov 16 15:56:18 2009, Fabio Forno wrote: >> On Mon, Nov 16, 2009 at 4:41 PM, Dave Cridland wrote: >> >> >> 1. Is this specification needed to fill gaps in the XMPP protocol >> stack or >> >> to clarify an existing protocol? >> > >> > I'm going to be forced to assume that the answer here is "No", given >> that >> > there's been no response to the Last Call at all. >> >> Indeed I sent a first attempt of review to the techreview list. > > Ooops. I seem to not be on that. > >> Basically it was positive (yes to 1,2,3, no to 4), I just think it >> doesn't state well real purpose (or at least what I find useful): the >> problem is not having overcomplicated stanzas to handle, but having >> some well defined method to understand which part of the message is >> the real payload, and which part is just a fallback (usually a body >> explaining why something has failed) > > Right. I also think a primary purpose of this document is, or should be, > some definitions of what these things are - so we know that we can say > that a XEP-0258 security label is a "Metadata element, as defined in > XEP-0226", or something - XEP-0258 almost does this, but making this > more stable and explicit would seem sensible. Yes, that is the gist of the Council discussion: http://logs.jabber.org/coun...@conference.jabber.org/2009-11-16.html#13:07:34 I think that makes sense, but I'm not sure when I'll have time to update XEP-0226 along these lines (probably in the next week or two). Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] LAST CALL: XEP-0226 (Message Stanza Profiles)
On Mon Nov 16 15:56:18 2009, Fabio Forno wrote: On Mon, Nov 16, 2009 at 4:41 PM, Dave Cridland wrote: >> 1. Is this specification needed to fill gaps in the XMPP protocol stack or >> to clarify an existing protocol? > > I'm going to be forced to assume that the answer here is "No", given that > there's been no response to the Last Call at all. Indeed I sent a first attempt of review to the techreview list. Ooops. I seem to not be on that. Basically it was positive (yes to 1,2,3, no to 4), I just think it doesn't state well real purpose (or at least what I find useful): the problem is not having overcomplicated stanzas to handle, but having some well defined method to understand which part of the message is the real payload, and which part is just a fallback (usually a body explaining why something has failed) Right. I also think a primary purpose of this document is, or should be, some definitions of what these things are - so we know that we can say that a XEP-0258 security label is a "Metadata element, as defined in XEP-0226", or something - XEP-0258 almost does this, but making this more stable and explicit would seem sensible. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] LAST CALL: XEP-0226 (Message Stanza Profiles)
On Mon, Nov 16, 2009 at 4:41 PM, Dave Cridland wrote: >> 1. Is this specification needed to fill gaps in the XMPP protocol stack or >> to clarify an existing protocol? > > I'm going to be forced to assume that the answer here is "No", given that > there's been no response to the Last Call at all. Indeed I sent a first attempt of review to the techreview list. Basically it was positive (yes to 1,2,3, no to 4), I just think it doesn't state well real purpose (or at least what I find useful): the problem is not having overcomplicated stanzas to handle, but having some well defined method to understand which part of the message is the real payload, and which part is just a fallback (usually a body explaining why something has failed) bye -- Fabio Forno, Ooros srl jabber id: f...@jabber.bluendo.com
Re: [Standards] LAST CALL: XEP-0226 (Message Stanza Profiles)
On Tue Oct 27 17:20:35 2009, XMPP Extensions Editor wrote: This message constitutes notice of a Last Call for comments on XEP-0226 (Message Stanza Profiles). Abstract: This document specifies best practices for generating and handling extended content in XMPP message stanzas. URL: http://www.xmpp.org/extensions/xep-0226.html This Last Call begins today and shall end at the close of business on 2009-11-13. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? I'm going to be forced to assume that the answer here is "No", given that there's been no response to the Last Call at all. Anyone any comments, before the Council meeting tonight? Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
[Standards] LAST CALL: XEP-0226 (Message Stanza Profiles)
This message constitutes notice of a Last Call for comments on XEP-0226 (Message Stanza Profiles). Abstract: This document specifies best practices for generating and handling extended content in XMPP message stanzas. URL: http://www.xmpp.org/extensions/xep-0226.html This Last Call begins today and shall end at the close of business on 2009-11-13. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
