[Standards] UPDATED: XEP-0313 (Message Archive Management)
Version 0.6.1 of XEP-0313 (Message Archive Management) has been released. Abstract: This document defines a protocol to query and control an archive of messages stored on a server. Changelog: [See revision history] (mw) Diff: https://xmpp.org/extensions/diff/api/xep/0313/diff/0.6/vs/0.6.1 URL: https://xmpp.org/extensions/xep-0313.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0333 (Chat Markers)
On Wed, Feb 15, 2017 at 6:45 PM, Sam Whited wrote: > I have reached out to the author to give them a chance to address > feedback, and to find out if they are still interested in maintaining > this XEP. > To give them time to respond, the LC has been extended until 2017-02-22. I spoke with the original author and they indicated that they would like me to find a steward for this document. Daniel Gultsch volunteered, and control of XEP-0333 has been passed on to him. To allow for him to make changes, and to allow for more feedback, the LC has been extended again to 2017-03-01. Best, Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0233 (XMPP Server Registration for use with Kerberos V5)
On Wed, Feb 8, 2017 at 4:50 PM, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0233 (XMPP > Server Registration for use with Kerberos V5). > … > This Last Call begins today and shall end at the close of business on > 2017-02-22. Due to a lack of feedback, the LC has been extended until 2017-03-01. Please submit your feedback by then. > 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? As far as I can tell. > 3. Do you plan to implement this specification in your code? If not, why not? No. I do not personally have a use for Kerberos auth (or know enough about it to be sure that my implementation was good). > 4. Do you have any security concerns related to this specification? > 5. Is the specification accurate and clearly written? I do not have enough domain knowledge to answer these questions. As far as I can tell, there are no security concerns, and the spec is clearly written. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)
On Thu, Feb 16, 2017 at 11:02 AM, Georg Lukas wrote: > My personal stance would be: discard , reference 334, be done > with it. However, that would probably require a namespace bump. I *think* I'm against continuing to reference 0334 here. While this hint is theoretically useful for other specs (eg. if there were some kind of pubsub-MAM-sync in the future that replaced carbons), I'm not sure we need to try and make it that reusable, and having it live in the spec that it's used for makes more sense to me (one less thing I have to click through to and read when implementing). I don't think it would greatly increase the complexity or length of this spec to include it, and I'm half convinced that 0334 needs to be split up and deprecated (it just feels like a lot of random stuff that doesn't belong together, but we can discuss that over on its thread), so I don't think this spec should rely on it. I am a fan, however, of deduplicating and only having one hint (I don't really care which, or what it's called; sounds good to me just because it's already in the spec). —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)
On Wed, Feb 8, 2017 at 5:07 PM, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0352 > (Client State Indication). > … > This Last Call begins today and shall end at the close of business on > 2017-02-22. FYI: I have extended the LC for this spec until 2017-03-01 to allow for more feedback. Please review by then. > 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? Yes. > 3. Do you plan to implement this specification in your code? If not, why not? Yes. > 4. Do you have any security concerns related to this specification? No. > 5. Is the specification accurate and clearly written? Yes. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0334 (Message Processing Hints)
On Wed, Feb 8, 2017 at 5:07 PM, XMPP Extensions Editor wrote: > This message constitutes notice of a Last Call for comments on XEP-0334 > (Message Processing Hints). > … > This Last Call begins today and shall end at the close of business on > 2017-02-22. I have extended the LC for this spec to 2017-03-01 as discussed in the council meeting today since it has not received much feedback. Please submit your feedback by that time. Thanks, Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0115 (caps): Validation string processing incomplete?
Hi, XEP-0115 (Entity Capabilities), §5.4 says this: > When an entity receives a value of the 'ver' attribute that appears to > be a verification string generated in accordance with the generation > method defined in this specification, it MUST process the 'ver' > according to the following method. It then goes on and states in Nr. 3: > If the value of the 'hash' attribute matches one of the processing > application's supported hash functions, validate the verification > string by doing the following: > > a) Send a service discovery information request to the generating >entity. > b) Receive a service discovery information response from the >generating entity. > [...] This requirement is stipulated unconditionally, which means, if I take it literally, I need to follow it *every time* I get a element with a 'ver' attribute, regardless of whether I cached the 'ver' value (validation string) or not. That in turn would mean I have to send service discovery queries each time I receive a element, which contradicts the motivation of XEP-0115 outlined in its §1 below the bullet list, as it would mean to send service discovery queries all the time when I receive stanzas (especially given that §6.1 says client SHOULD send the capabilities information with every stanza). Shouldn't there be a list item in §5.4 before Nr. 3 a) that says something like "If the verification string received is equal to a verification string already validated and cached using the mechanism outlined below, stop processing here"? I see that in Nr. 3 h) I am advised to cache the result value, but this doesn't play good with the hard MUST requirement at the beginning of §5.4 that doesn't take the cache into reference. The only reason I could imagine to query for a cached verification strings' entity service discovery information is a broken client that sends out the same verification string even if it changes features, but that is a case that I think shouldn't be catered for as it is a clear violation of the generation of the validation string as described in §5.1. Any insights? Marvin -- Blog: https://www.guelkerdev.de PGP/GPG ID: F1D8799FBCC8BC4F ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] 2017-02-22 Council Meeting Minutes
Link to log: http://logs.xmpp.org/council/2017-02-22/#16:01:02 1) Roll call - Daniel - Sam - Link Mauve - Dave - Tobias (chairing) 2) minute taker - Daniel volunteers 3) outstanding votes - Tobias reminds people to vote on 2 proto xeps and 2 other voting issues (LC for IoT SIG and LC for XEP-0186) 4) clarify CSI and Carbons State after resume - Tobias asks people to review the PRs on Github and provide feedback: https://github.com/xsf/xeps/pull/402 5) LC for chat markers has ended. Daniel takes over as author. plans to make changes 6) voting on advancing XEP-0368 to draft https://xmpp.org/extensions/xep-0368.html Tobias on list Sam +1 Daniel +1 Link Mauve on list Dave +1 7) date of next Tuesday February 28th 1600Z 8) AOB - Sam notes that LC has ended for XEP-0233, 0280, 0334, 0352 - Due do general lack of feedback Sam will extend the LC's ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)
* XMPP Extensions Editor [2017-02-09 00:07]: > This Last Call begins today and shall end at the close of business on > 2017-02-22. As outlined in the "Carbon Rules for MUC-PMs" mail[0], here are two PRs against 0045 and 0280: https://github.com/xsf/xeps/pull/436 "XEP-0045: Add tag to MUC-PMs" (the wording might not be perfect yet, but should be clear) https://github.com/xsf/xeps/pull/434 "XEP-0280: Rewrite of the 'Messages Eligible for Carbons Delivery' section": This PR combines multiple changes, ordered by level of controversy. - aac8f94 Removal of the `private` element, as +1ed by @linuxwolf in [1] - this requires a version bump IMO, as it changes the server behavior when parsing messages with only the `private` element present. - f0e432c Improvement of the "Messages Eligible for Carbons Delivery" section that conveys the same set of rules in less words - 7f529e1 addition of clear MUC / MUC-PM instructions, as suggested in [0] - c60ec80 minor wording correction to accomodiate the above changes - 9c388a5 controversial change of the "Messages Eligible for Carbons Delivery" languge from "serves MAY do this" to "servers SHOULD do this". The language in the old XEP is very vague and non-binding, and this patch attempts to make clearly defined rules for clear use cases, so that clients can expect consistent behavior (even though they may not rely on it). Kind regards, Georg [0] https://mail.jabber.org/pipermail/standards/2017-January/032048.html [1] https://mail.jabber.org/pipermail/standards/2017-February/032271.html -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e h- r++ y? || ++ IRCnet OFTC OPN ||_|| signature.asc Description: Digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
