On Mon, Mar 20, 2017 at 12:50 PM, XMPP Extensions Editor
wrote:
> URL: https://xmpp.org/extensions/inbox/isr-sasl2.html
> Example 2. An xmlns:isr='urn:xmpp:isr:0' \ isr:mechanism='X-HT-SHA-256-ENDP'/>
I don't think that namespaced attributes are necessary; they add
complication, don't work with
On Wed, Mar 22, 2017 at 12:48 PM, wrote:
> Last Updated: 2017-03-27, looks like someone in the XSF got a DeLorean
Sorry, I didn't notice this until after I'd already published. Will
try to be better about verifying this sort of thing in the future.
—Sam
_
TL;DR — Privacy lists don't give us anything that we actually want to
have that the blocking command doesn't give us already, and they're
too complicated.
Hi all,
I would like to restart the discussion on deprecating XEP-0016:
Privacy Lists [1] in favor of XEP-0191: Blocking Command [2].
Current
On Wed, Mar 22, 2017 at 2:28 PM, Yann Leboulanger wrote:
> One nice feature we also don't have with blocking command is blocking a
> while group.
Ah yes! I knew there was something else that I was forgetting to
address from last time.
I also think this is not a good thing; it is an abuse of ros
On Thu, Mar 23, 2017 at 8:09 AM, Dave Cridland wrote:
> I'm in favour of deprecation (but not elimination).
I forgot there was a difference, but I used the word I meant purely by accident.
To make sure it's absolutely clear: I am advocating that we move
XEP-0016 to the "Deprecated" stage describ
On Wed, Apr 12, 2017 at 6:43 AM, Daniel Gultsch wrote:
> 4) Vote on advancing XEP-0334: Message Processing Hints
> Everyone to vote on list.
-1
I've thought about this some more, and I still don't think it makes
sense to have a "hints" XEP. In my opinion we should move towards
obsoleting this XE
On Wed, Apr 12, 2017 at 9:20 AM, Tobias M wrote:
> Which XEPs need changes in response to this? Do the hints get under a
> different namespace?
Just MAM and Carbons, I think. Yes, in my opinion these sorts of
thihngs should be namespaced with the spec that uses them.
—Sam
__
On Wed, Apr 19, 2017 at 9:29 AM, Tobias M wrote:
> Having an own XEP for each hint feels a bit over the top.
I agree, let's not do this.
> Moving each hint to the XEP that uses it would lead to duplication of hints
> or one XEP using
> a hint defined in an otherwise unrelated XEP.
Is there a r
On Wed, Apr 12, 2017 at 10:14 AM, Dave Cridland wrote:
> I'd be interested in Sam's counter-arguments, mind.
- Discoverability: if or or whatever is only
used from carbons, why do I have to click through to a different long
XEP to find the one hint that I care about while I'm implementing
carbo
On Thu, Apr 20, 2017 at 3:47 AM, Dave Cridland wrote:
> What about MUC web logs?
Presumably if they're not using some custom API they have to support
parsing MUC messages with a separately namespaced child anyways, so
they can parse the hint regardless of what the namespace is.
Admittedly, it wou
# 2017-04-26 Council Meeting
Logs: Logs currently offline
## Roll call
- Tobias (chairing)
- SamWhited
- inputmice (aka "Different account daniel")
- Link Mauve
- Dave Cridland
## SHA-1 Migration Plan
Tobias and Link Mauve to sync after the meeting to determine what needs to be
done. No prog
Fair warning, I'm not fully up to date on this discussion, but I was
asked to drop some notes from the room earlier into the thread so here
I am, this message from Daniel appears to be a good place to start.
On Thu, Apr 27, 2017 at 10:56 AM, Daniel Gultsch wrote:
> as mentioned several times in v
# 2017-05-10 Council Meeting
Logs: logs are down
## Roll call
- Daniel (chairing)
- SamWhited
- Link Mauve
- Dave Cridland
- Tobias (absent)
## SHA-1 Migration Plan
No progress to report.
## Date of next
2017-05-17T15:00Z
## AOB
- Peter Waher has asked for the IP he assigned to the XS
On Wed, May 10, 2017 at 12:41 PM, Jonas Wielicki wrote:
> Secondly, since Client 2 needs to know of the protocol in any case, can we
> maybe elide the server of Client 2 from the equation? Then the usability of
> tokens doesn’t depend on the server of Client 2 but only on the client.
>
> That woul
On Wed, May 10, 2017 at 1:41 PM, Daniel Gultsch wrote:
> The business logic consists of a definition on how to convert a timestamp
> into a sequence of bytes and hmacing that with a secret key from a PEP node.
> That's it. (And converting that to base64.) Different people might have
> different de
On Wed, May 10, 2017 at 2:29 PM, Daniel Gultsch wrote:
> IMHO the hypothetical service operators who maintain their own service which
> are self-branded are very welcome to step forward now and try to get their
> use case covered but keeping them in mind without knowing who they are is a
> waste o
On Wed, May 10, 2017 at 3:08 PM, Sam Whited wrote:
> can be flexible but not introduce unnecessary complexity, which I
> think this does, it seems like a good idea to me.
which I DON'T think this does, that is. D'oh.
To be clear, I think the server approach is less complex, a
On Thu, May 11, 2017 at 2:34 AM, Georg Lukas wrote:
> Sam, could you imagine elaborating a bit more of your potential business
> use case and how you see it conflict with HMAC-tokens?
I'm not sure that there's much more to say; I don't have a specific
use case in mind other than I think lots of p
On Sat, May 20, 2017 at 10:21 AM, Evgeny Khramtsov wrote:
> I wonder what privacy list should be consulted before storing a message
> in MAM archive: default or active? I think this should be the default
> list, but I'd like to clarify.
Privacy lists have been deprecated by the council (I just ac
On Sat, May 20, 2017 at 10:45 AM, Evgeny Khramtsov wrote:
> Which doesn't mean everyone should delete the corresponding code.
I agree, which is why I said no such thing.
>> I would avoid making more code dependent on it.
>
> I'm not sure what this means and how it's relevant to the question.
I
On Wed, May 24, 2017 at 11:04 AM, Dave Cridland wrote:
> Firstly, section 6 of XEP-0001 clearly states that the Author's job is
> to gather and incorporate feedback from the community during the
> lifetime of the XEP. It also clearly states that the XEP author should
> be subscribed to this mailin
On Wed, May 24, 2017 at 11:36 AM, Daniel Gultsch wrote:
> Side note: We also have *a lot* of XEPs which are inactive for way
> more than 6 month where there is no activity whatsoever. No questions,
> no discussions, no implementations. Are we just going to defer them?
> Or is the 6 month of inacti
On Wed, May 24, 2017 at 11:54 AM, Dave Cridland wrote:
> I see it as a requirement for the role in Council. Otherwise how can
> one judge whether there are outstanding problems?
I think it's not terribly difficult to keep an eye on the community
and what's going on without having read all the arg
>> Sam and Dave think it still involves manual steps.
>
> It does, as it has always done.
Those manual steps have never involved being dependent on another team
though, which is the actual problem.
On Fri, May 26, 2017 at 3:31 AM, Kevin Smith wrote:
> I did say that the Editor scripts to send ma
On Fri, May 26, 2017 at 9:10 AM, Kevin Smith wrote:
> I’ve now given the editors the ability to deploy a new docker image with the
> aforementioned script.
Thank you; one down.
> email is an issue of Editor tooling, rather than iteam, and we can resolve
> that there.
Is it? I don't think it's
On Fri, May 26, 2017 at 9:43 AM, Kevin Smith wrote:
> In the meantime, I’ve set up mail on the host and confirmed it can send to
> XSF lists as edi...@xmpp.org.
Thanks, that seems to be working; hardhats on for incoming mail flood please!
—Sam
___
Sta
> Yes, it's true that there's currently no such thing [a permissively licensed
> implementation] for XEdDSA …
> implementing this yourself really isn't
> that complex. You can re-use existing EdDSA code, all you need to do is
> write the key conversion code yourself, for which there is pseudo-code
On Fri, May 26, 2017 at 12:15 PM, Remko Tronçon wrote:
>> crypto is subtle, and it can be very easy to make mistakes that have
>> catastrophic consequences.
>>
>> ...
>> I haven't finished or tested it yet
>
>
> This doesn't really give me much more confidence to be honest.
Fair enough; the point
On Fri, May 26, 2017 at 7:27 PM, Remko Tronçon wrote:
> - We change the XEP to use XEdDsa, and someone gets an implementation into
> an (peer reviewed and preferably established) crypto library, *independent*
> of libolm.
In its most basic form XEdDSA just requires being able to convert keys
from
On Sat, May 27, 2017 at 3:41 PM, Remko Tronçon wrote:
> And you got all this just by looking at the XEdDSA spec? Maybe to you this
> is trivial, but I don't understand how parts of the pseudocode in the spec map
> to the code you wrote (e.g. the ScCMove bit is pure magic to me, I would
> never hav
On Sun, May 28, 2017 at 5:31 AM, Dave Cridland wrote:
> The comments are identical, and the variable names and code structures
> are identical.
>
> My conclusion would be that the Go version is a clear-cut derivation
> of the libsignal code, and thus a derived work (in copyright
> language), and t
On Sun, May 28, 2017 at 9:37 AM, Sam Whited wrote:
> That's correct, it is almost identical, just as their version is
> almost (exactly?) identical to the ed25519 reference implementation.
Sorry, left off the link, the public domain reference implementation
can be found in t
On Sun, May 28, 2017 at 1:15 AM, Remko Tronçon wrote:
> Is this really true? You can do *a lot* of branches+memcpys for 3 loops over
> all data as far as I know. I would have guessed this was a measure against
> timing attacks. Where is this CMov coming from?
In this case I don't *think* timing a
On Sun, May 28, 2017 at 9:53 AM, Sam Whited wrote:
> If you're curious, feel free to ping me out of band
> (s...@samwhited.com, email or JID) and I can send you the code it
> generates; there are definitely no jumps there, and it's actually
> quite interesting :)
No branch
On Sun, May 28, 2017 at 10:40 AM, Remko Tronçon wrote:
>> You'll notice that most (all?) of OWS's ed25519 code was
>> copied from here,
>
> AFAICT, everything under additions/ is either new or modified ref10 code
> (_modified.*),
> hence only available under a GPL license. This includes sc_neg.c,
> price we're willing to pay?
>
> Remko
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> __
On Wed, May 31, 2017 at 2:35 PM, Dave Cridland wrote:
> I call bullshit.
>
> He copy and pasted some code (and the comments!).
>
> The fact he did this then submitted it to another project without
> attribution and flouting the licensing is actually besides the point -
> I have no idea in what par
On Wed, May 31, 2017 at 2:59 PM, Dave Cridland wrote:
> But you did copy, amongst possibly other things, a constant-time
> conditional-swap routine, along with the comments, from the
> "additional" directory of a GPL library, so I can only assume that
> copyright law works an entirely different wa
On Wed, May 31, 2017 at 3:27 PM, Ignat Gavrilov
wrote:
> 1. Does this even work? I think the Signatures made using Ed25519 on your
>"non-libsignal" side (which not necessarily includes all non-libsignal
>implementations) will not be verifiable on the libsignal side and
>vice-versa.
It
On Wed, Jun 7, 2017 at 1:22 PM, Ignat Gavrilov
wrote:
> I would propose that those people, who think that those who proposed UX
> breaking changes start putting their effort into OMEMO-NEXT and leave the
> OMEMO people working on "their standard". No reason to torpedo each other. We
> could jus
On Thu, Jun 8, 2017 at 4:08 PM, Dave Cridland wrote:
> I'm considering advising Board that we should address this by
> instituting a policy whereby changes to XEPs result in all listed
> authors being notified (a PR will do, I imagine), and those who do not
> respond within a reasonable time (hand
# Roll call
- Tobias (chairing)
- daniel
- Dave Cridland
- Sam Whited
Link Mauve absent
# Editor
Editor still needs to merge and catch up on PRs / figure out the new deployment
process.
Sam apologizes for being behind.
# The OMEMO Situation (starting Connie Nielsen and Damien Lewis
On Thu, Jun 15, 2017 at 10:15 AM, Florian Schmaus wrote:
> Like when? Most, if not all, things in XMPP are context sensitive, and
> we already re-use the same element in different contexts in XEPs.
Can you give an example? I don't think this is true; remember that
elements are qualified by the lo
On Thu, Jun 15, 2017 at 10:38 AM, Florian Schmaus wrote:
> You misunderstood.
>
> The point here is that a element as child
> of , is different than xmlns='urn:xmpp:mix:1'/> as child element of xmlns='jabber:client'/>.
Only by convention or as part of the application logic; as far as a
parser
On Sat, Jun 17, 2017 at 1:15 AM, Remko Tronçon wrote:
>> This Last Call begins today and shall end at the close of business on
>> 2017-03-14.
>
> FYI, this XEP seems to be in last call after its end date.
This one was waiting on some updates based on list feedback, IIRC, but
it's been long enough
On Wed, Jun 21, 2017 at 9:53 AM, Peter Saint-Andre wrote:
> The OMEMO saga (of which I am only a distant observer) raises a more
> general issue: leaving a specification in the ProtoXEP state for way too
> long.
OMEMO is actually in experimental; so I'm not sure this applies to the
OMEMO discussi
On Wed, Jun 21, 2017 at 10:47 AM, Daniel Gultsch wrote:
> XEP-0001. We have countless - very essential - stuck in
> very low ranks like experimental and draft. This leads to developers
> implementing (and deploying to large user bases) experimental and
> draft XEPs (which they are not really suppo
On Wed, Jun 21, 2017 at 12:03 PM, Daniel Gultsch wrote:
> I'm open to comments on whether people think hosting it in the attic
> or on my own web space is the better idea here.
I certainly think it would be better to have it somewhere "official"
(in the XSF's webspace).
I do not see anyone as tr
On Wed, Jun 21, 2017 at 11:30 AM, Ignat Gavrilov
wrote:
> We might release some of our non-libsignal-based development later this year
> as open-source, but I bet it will be GPL licensed and not under one of those
> "make money with third-party software and run away with it"-licenses that are
>
On Thu, Jun 22, 2017 at 3:30 AM, Dave Cridland wrote:
> If it really is the name, then let's call it "Stable".
I actually do think that would be very helpful; I can't tell you how
often random people I'm talking too say "we tried XMPP, but it didn't
have the feature we wanted" and I say "sure it
# 2017-06-28 Council Meeting
Logs: logs are down
## Roll call
- daniel (chairing)
- Sam Whited
- Dave Cridland
- Link Mauve
Tobias absent
## Compare & Publish
- ProtoXEP still not in inbox, so no vote yet
## OMEMO-NEXT
- Council to seek a new author
- Sam and vanitasvitae ask if
On Tue, Aug 8, 2017, at 04:09, Daniel Gultsch wrote:
> That's why I suggest to explicitly limit the XEP to message stanzas
> (for now). If we in the future want to expand that XEP to more stanzas
> (and expand the rules on sanitizing fake IDs) we can remove that
> wording and bump the namespace.
On Wed, Aug 9, 2017, at 06:47, Georg Lukas wrote:
> With the above points considered, Hints would be reduced to a single
> "no-archive" or "transient" hint, making it a rather thin XEP.
That seems reasonable to me if this is the extent of the problem.
Alternatively, do we not have a more general "
On Tue, Aug 15, 2017, at 10:12, Dave Cridland wrote:
> * now talks about "tasks" rather than special SASL
> mechanisms. Tasks have essentially the same interface as SASL mechs,
> but do different things - trying to shoehorn them into the same thing
> wasn't mentally working for me, and for some re
On Tue, Aug 15, 2017, at 11:14, Paul Schaub wrote:
> Do you think it might be a good idea to add a session-info element which
> can be used to specifically request the checksum of a file?
My guess is that the reasoning for allowing the checksum to be sent
later is that the server (or some file-sto
On Thu, Aug 10, 2017, at 04:57, edhelas wrote:
> *What else are we searching for?*
> We would be interested in the XSF, as an organization itself, to join
> our project´s External Advisory Board. The EAB would meet twice within
> the projects duration to discuss the main ideas and outcome of the
On Thu, Aug 17, 2017, at 15:23, Paul Schaub wrote:
> I propose the following change: The session-initiate MUST contain a
> reference to the hash algorithm used to calculate the checksum. The
> actual hash-value can still be send afterwards, but now the receiver can
> calculate the hash on the fly.
ttachments:
> + poezio.xml
> 14k (application/xml)
> + parser.py
> 8k (text/x-python)
> + signature.asc
> 1k (application/pgp-signature)
--
Sam Whited
s...@samwhited.com
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
On Fri, Aug 25, 2017, at 06:33, Dave Cridland wrote:
> Comments are most welcome!
The only thing I think needs to be changed right now, though it sounds
minor, is that the response to select the SASL stream feature does not
match the feature advertised. The server offers "" and the
client responds
On Fri, Aug 25, 2017, at 09:22, Dave Cridland wrote:
> So the problem with that is that the schemas for the feature and the
> (same-named) top-level element wouldn't match.
That seems fine to me, but I also don't understand XML schema so I might
just not understand why that's a problem. How do oth
On Fri, Aug 25, 2017, at 11:59, Evgeny Khramtsov wrote:
> Maybe a significant reduction in RTT, but this is a little part of the
> whole session traffic (the large part of which are pointless presences
> and some PEP). So you will connect in 1 second instead of 2. No? Then
> do you have benchmarkin
On Fri, Aug 25, 2017, at 12:22, Evgeny Khramtsov wrote:
> But why do you wait for the stream to be established? You can write
> messages to a buffer, you already have one anyhow if you support
> XEP-0198. This is a problem of a bad UX, not the protocol.
Then it's an even worse UX when auth fails a
On Wed, Aug 30, 2017, at 11:30, Daniel Gultsch wrote:
> No not necessarily. It boils down to how good does a XEP have to be to
> be accepted as Experimental.
In my mind the criteria is "could I create an experimental
implementation of this spec that would be interoperable with other
experimental i
On Thu, Aug 31, 2017, at 08:53, Peter Saint-Andre wrote:
> I realize people voiced a concern with not being able to develop to the
> spec right away. That's why it's 0.1. Coders aren't stupid, they realize
> that 0.1 means it's early days. If they run into ambiguities, they'll
> provide feedback on
On Thu, Aug 31, 2017, at 08:49, Guus der Kinderen wrote:
> On 31 August 2017 at 15:37, Peter Saint-Andre wrote:
> > There is: the Council blocking publication of XEPs. Publish the thing,
> > get it into XSF processes, and work on the spec in the right way. Ship
> > and iterate!
> >
> > Which has b
Membership benefits include:
- Ability to join certain restricted working groups (council, editors)
- Free dinner for you and a guest at Summits
- One vote in (rare) important decisions that need to be brought before
the members
On Sat, Sep 2, 2017, at 06:48, Evgeny Khramtsov wrote:
> This is mos
On Tue, Sep 5, 2017, at 03:07, Evgeny Khramtsov wrote:
> After we started receiving subscriptions from spammers I actually
> started to think to remove subscription text on server side :)
Removing the text doesn't seem like an appropriate solution to me in
general. Presumably this means you get a
On Tue, Sep 5, 2017, at 09:24, Evgeny Khramtsov wrote:
> Shouldn't a client provide a straightforward way to request the vCard?
> Because that's what I do before accepting any subscriptions (I
> personally deny requests with empty vCards immediately).
I would probably do the same if I got a reques
On Wed, Sep 6, 2017, at 01:44, Remko Tronçon wrote:
> (e.g. no IBR, harder proof of validity)
XEP-0389 [1] was written to help with this. Feedback, implementations,
and mechanisms to make mass registrations harder are appreciated.
—Sam
[1]: https://xmpp.org/extensions/xep-0389.html
_
On Fri, Sep 8, 2017, at 05:05, Remko Tronçon wrote:
> - Provide a hash of the contents in the , such that the server
> can
> make decisions on upload slot response based on the hash (e.g. give a
> response that this file has already been uploaded).
I like this idea.
> - The ability to omit the f
On Mon, Sep 11, 2017, at 12:13, Jonas Wielicki wrote:
> XEP-0377 (Spam Reporting) has been Deferred because of inactivity.
Hi all. Spam reporting was just (correctly) deferred. Several servers
have implemented it, but only a handful of operators and client
developers, as far as I can tell so I wan
On Mon, Sep 11, 2017, at 14:56, Evgeny Khramtsov wrote:
> I actually reported the issue here:
> https://mail.jabber.org/pipermail/standards/2017-January/031883.html
>
> TL;DR: I don't like the inclusion of element inside
> element and, thus, will not implement it in such form. There should be
>
On Mon, Sep 11, 2017, at 15:21, Guus der Kinderen wrote:
> The integration with block is an optional part of the XEP, isn't it? I'm
> reading it as: spam can be reported to any entity that advertises
> support,
> and could be inlined with Block if/when desired.
Right now the only mechanism for rep
On Mon, Sep 11, 2017, at 15:29, Guus der Kinderen wrote:
> I'm not sure if the "reporting" bit should automatically go hand in hand
> with "blocking" specifically. There might be value in defining an entity
> that simply just receives spam reports. Obviously, end-users generally
> report spam becau
On Mon, Sep 11, 2017, at 15:39, Evgeny Khramtsov wrote:
> What if we decide to report SPAM to a separate entities?
That is out of the scope of this spec; that's more complicated, and is
not something that is allowed by this specification.
> Really, we're now creating problems out of nothing.
I d
On Mon, Sep 11, 2017, at 16:08, Holger Weiß wrote:
> Your assumption might be right or wrong. Using a separate query copes
> with both cases.
It also means the block and the spam report are no longer correlated and
that there are more round trips with the server. Both of these don't
seem desirabl
On Mon, Sep 11, 2017, at 16:29, Evgeny Khramtsov wrote:
> Let me answer. Because he thinks that those two actions should be
> always performed together. But in this case why do we need to have a
> spam reporting mechanism? Let's assume that the blocked person is
> always a spammer.
Maybe this shou
On September 11, 2017 4:44:27 PM CDT, Evgeny Khramtsov
wrote:
>So, probably? Or are you absolutely sure?
No, but this isn't designed to be a one size fits all solution to every problem
under the sun, it's supposed to provide a simple, easy to implement solution
for saying that you blocked som
On Mon, Sep 11, 2017, at 17:39, Evgeny Khramtsov wrote:
> Deprecating something doesn't magically solve the problem and force
> operators/users to update software (remember vcard avatars or private
> storage, though, they are not formally deprecated, but deprecation will
> not change anything). So
On Mon, Sep 11, 2017, at 17:51, Evgeny Khramtsov wrote:
> Well, actually I'm open to find a compromise. If the author insists on
> wrapping it into element and says that this is a "blocking
> reason", then I'm fine with defining this in XEP-0191. This should not
> be a problem, right? Because it's
On Mon, Sep 11, 2017, at 17:39, Kim Alvefur wrote:
> The SPAM payload itself is of interest for further analysis, so a way to
> get it would be nice. But we don't want to make it easy to lie and
> submit something and claim it came from an innocent. Perhaps a message
> id, that could be corelated w
On Tue, Sep 12, 2017, at 09:16, Holger Weiß wrote:
> But I still believe it's wrong to let one feature depend on another one
> without a technical reason. Dependencies can lead to issues
Would not making it a dependency and merging it into the Blocking XEP
solve this for you as well?
—Sam
__
On Tue, Sep 12, 2017, at 10:06, Evgeny Khramtsov wrote:
> And say bye-bye to namespace delegation?
Does namespace delegation only work on top level IQs (I guess it would
have to unless you wanted to do some weird forward-lookahead type
stuff)? I hadn't actually considered it because I didn't know
On Wed, Sep 13, 2017, at 14:05, Jonas Wielicki wrote:
> On Dienstag, 12. September 2017 14:21:41 CEST Paul Schaub wrote:
> > Heyho!
> >
> > I just created a PR that addresses some of your feedback. A rendered
> > version can be found here: https://geekplace.eu/xeps/xep-jet/xep-jet.html
> >
> > Lo
Apologies for the massive amount of stuff this week; it was a busy
meeting due to some annoying editor who decided to do a ton of
maintenance stuff all in one big batch…
--
# 2017-02-08 Council Meeting
Logs: http://logs.xmpp.org/council/2017-02-08#16:00:55
## Roll call
- Tobias (chairing)
- S
>
> URL: http://xmpp.org/registrar/disco-features.html
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___________
On Tue, Sep 19, 2017, at 11:15, Jonas Wielicki wrote:
> * Do we need to interact with some registry to get xmpps-server and
> xmpps-
> client SRV record service names registered? From my understanding, SRV
> records
> can use the names as assigned in [3] or "locally defined" (whatever that
> mean
On Tue, Sep 12, 2017, at 07:21, Paul Schaub wrote:
> I just created a PR that addresses some of your feedback. A rendered
> version can be found here: https://geekplace.eu/xeps/xep-jet/xep-jet.html
Thanks!
> Split up the protocol into encryption method specific sub protocols
> (jet-omemo, jet-o
Management
- XEP-0377: Spam Reporting
- XEP-0378: OTR Discovery
—Sam
--
Sam Whited
s...@samwhited.com
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
On Sat, Sep 23, 2017, at 15:51, Sam Whited wrote:
> If you notice anything that looks amiss, please let an
> editor know by replying to this email.
My apologies, that list was generated from the wrong commit and should
not have been sent. Please disregard.
On Mon, Sep 25, 2017, at 03:33, Dave Cridland wrote:
> I'd actually prefer the spam.
>
> It's useful for the formal record, I think, and for the easy ability
> to search for it later.
It's too much of a pain to generate when there are lots of changes
though (not that there actually were this time
On Wed, Sep 20, 2017, at 10:46, JC Brand wrote:
> 2) Vote on accepting "Jingle Encrypted Transports" as Experimental XEP
+1
—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.
On Tue, Sep 26, 2017, at 06:15, Dave Cridland wrote:
> > Should we rename the status names that we use in XEPs? One of the recurring
> > criticisms about XMPP that I read is "Pretty-standard-feature XYZ has a XEP
> > that is only "experimental"! By doing some window dressing, we will improve
> > th
On Tue, Sep 26, 2017, at 12:37, Ivan Vučica wrote:
>
> On 26 September 2017 at 14:47:27, Sam Whited (s...@samwhited.com) wrote:
>
> As others have said, the real naming problem is "draft". We can't
> actively advance draft as much (since final really is final and
On Tue, Sep 26, 2017, at 14:19, Ivan Vučica wrote:
> And now, to bikeshed a bit on the proposed naming: To a casual reader,
> stable has similar implications as final. Especially if said reader is
> used to Debian's use of the word.
That seems like exactly what we want.
—Sam
_
On Wed, Sep 27, 2017, at 02:08, Kevin Smith wrote:
> Are they not then going to be upset if there are backwards-incompatible
> changes in a new namespace? We try not to do that in Draft XEPs, but
> that’s the reason they’re Draft rather than Final, to give us that
> option.
"Stableish"?
—Sam
Hi all,
It's time for another round of reviews of the 2017 Compliance Suites
[1]. I think all the changes that people suggested last time have been
addressed. Anything else before we move it to the official
recommendation?
—Sam
[1]: https://xmpp.org/extensions/xep-0387.html
--
Sam Whi
On Fri, Sep 29, 2017, at 05:38, Florian Schmaus wrote:
> But this leads to a very ugly protocol design where an additional extension
> element carrying the mapping information from item ID to item "version"
> is required. I think this is good case very namespaced attributes would
> really shine.
A
On Fri, Sep 29, 2017, at 09:30, Florian Schmaus wrote:
> I don't think we should (or even could) inject stuff into the item's
> payload.
Please elaborate.
—Sam
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscri
On Tue, Oct 3, 2017, at 08:43, vaibhav singh wrote:
> some XMPP clients send their own pings whose timeouts
> cannot be configured. This results in ping-pong packets coming and going
> around a lot, and awkward interactions (the client may think that the
> server is down but server may not, in case
1 - 100 of 708 matches
Mail list logo
