Am Samstag, dem 28.10.2023 um 14:40 +0100 schrieb Matthew Wild:
>
> So, SSDP "only" allows the client to detect the difference between
> two cases:
>
> 1) The real server advertises new channel binding methods the client
> does not understand
> 2) An MITM is trying to trick the client into
Am Mittwoch, dem 11.08.2021 um 14:25 -0600 schrieb Peter Saint-Andre:
> Too bad we didn't stick to our guns in 2003 and insist on two ports
> instead of one, but STARTTLS was the recommended approach back
> then...
>
I am still not convinced the STARTTLS is ultimate evil. SMTP had way
too many
Am Mittwoch, dem 10.02.2021 um 19:37 +0100 schrieb Thilo Molitor:
> > I cannot recall now where exactly it was but there was definitelly
> > something about the order of the fields somewhere, because I
> > remember
> > adding a separate list with original key order to be able to use
> > hashmap
Am Mittwoch, dem 10.02.2021 um 17:28 +0100 schrieb Jonas Schäfer:
> Thanks for the minutes!
>
>
> As of now, I’m still -1.
>
> I want to elaborate the reason a little. Note that my -1 is solely
> based on
> the ordering requirement for , not the other commit in
> that PR.
>
> I am not aware
Am Donnerstag, den 19.11.2020, 18:10 +0500 schrieb Andrew Nenakhov:
> So of course, we use HTTP
> for hosting sticker packs and stickers themselves, and any client on
> any OS can *easily* import any image by their URIs. This way clients
> do not need to use pubsub or anything, just use the links,
Am Mittwoch, den 04.11.2020, 11:46 + schrieb Dave Cridland:
>
> Due to network analysis (and "thanks" to a bug in the server which
> caused some useful logging), we were able to examine not only when
> sessions went into the unresponsive state, but also when the client
> subsequently sent
Am Freitag, den 23.10.2020, 15:04 + schrieb Tedd Sterr:
> (This is tangential to Dave's thread, but I didn't want to hijack
> that, hence a new one.)
>
> There may be some argument to include the url in the body anyway for
> backwards compatibility, but given the XEP is over 14 years old and
Am Mittwoch, den 21.10.2020, 16:28 +0100 schrieb Dave Cridland:
>
> This specification is primarily intended for, and used for, the
> purpose of transferring a file from one user to another.
>
> In practise, the clients upload a file, thereby obtaining a URL, and
> pass that URL somehow to the
Am Dienstag, den 20.10.2020, 14:31 + schrieb Jonas Schäfer:
> The XEP Editor would like to Call for Experience with XEP-0363 before
> presenting it to the Council for advancing it to Final status.
>
>
> During the Call for Experience, please answer the following
> questions:
>
> 1. What
Am Montag, den 28.09.2020, 09:51 +0100 schrieb Dave Cridland:
>
>
> On Sun, 27 Sep 2020 at 16:46, Holger Weiß
> wrote:
> >
> > I think it would be good to find a better solution.
>
> OK, just out of curiosity, why?
I for one want that to be formalized.
So far the formal response to that
Am Sonntag, den 27.09.2020, 17:45 +0200 schrieb Holger Weiß:
> When opening a new session, MAM clients might want to use the
> most-recent known XEP-0359 stanza ID to sync messages. One problem
> they
> face is that there's no way to figure out the stanza ID of outgoing
> messages, short of
Am Mittwoch, den 02.09.2020, 16:23 +0100 schrieb Dave Cridland:
> Hey all,
>
> Really simple questions, so please do reply and answer:
>
> If you have an XMPP product or public project, do you claim
> compliance with XEP-0423?
>
> If you do not claim compliance, are you aiming for compliance
Am Samstag, den 29.08.2020, 09:15 +0200 schrieb Philipp Hörist:
> Hi,
>
> Just to be clear, the XEP mandates protocol features, not a default
> config on your PubSub Service.
>
> Default config does not make much sense, as other XEPs would need
> another configuration, that would mean we would
Am Samstag, den 29.08.2020, 08:37 +0200 schrieb Philipp Hörist:
> Am Sa., 29. Aug. 2020 um 08:16 Uhr schrieb Ruslan N. Marchenko <
> m...@ruff.mobi>:
> > The way I read it initially was "pubsub service MUST support
> > persitent items" but it seems it really
Am Samstag, den 08.08.2020, 09:22 +0200 schrieb Philipp Hörist:
> Hi,
>
> Note that major server implementation don’t support checking all
> fields they support with publish-options
>
> Means only because a server supports max_items, it does not mean it
> can check the value via publish-options.
Am Samstag, den 08.08.2020, 07:13 + schrieb Daniel Gultsch:
> Am Sa., 8. Aug. 2020 um 07:07 Uhr schrieb Ruslan N. Marchenko <
> m...@ruff.mobi>:
> >
> > I.e. I know the form can contain any arbitrary data just wonder if
> > any
> > implementatio
Hi Standards,
I'm trying to extend PEP server implementation to support OMEMO and
stumbled upon following issue: the OMEMO 5.3.2 stipulates the max_items
should be specified in the publish-options form, however neither form
registry nor XEP-0060 allow anything but access-model in the publishing
Am Dienstag, den 04.08.2020, 16:05 + schrieb XEP Editor Pipeline:
> This message constitutes notice of a Last Call for comments on
> XEP-0352.
>
> Title: Client State Indication
> Abstract:
> This document defines a way for the client to indicate its
> active/inactive state.
>
> URL:
Am Dienstag, den 21.07.2020, 19:28 +0100 schrieb Dave Cridland:
> On Tue, 21 Jul 2020 at 18:57, Florian Schmaus
> wrote:
> > Based on the discussion in this thread, I suggest the following
> > changes
> >
> >
> >
> > http://geekplace.eu/xeps/xep-sasl-cb-types/diff.html#sasl-mech-interaction
>
Am Donnerstag, den 16.07.2020, 13:08 +0200 schrieb Ruslan N. Marchenko:
> Am Donnerstag, den 16.07.2020, 10:33 + schrieb Daniel Gultsch:
> > Am Do., 16. Juli 2020 um 10:13 Uhr schrieb Florian Schmaus <
> > f...@geekplace.eu>:
> >
> > > If you send 'y', whi
Am Donnerstag, den 16.07.2020, 10:33 + schrieb Daniel Gultsch:
> Am Do., 16. Juli 2020 um 10:13 Uhr schrieb Florian Schmaus <
> f...@geekplace.eu>:
>
> > If you send 'y', which implies that you, the client, did not select
> > a
> > -PLUS mechanism for authentication, while the server
Am Dienstag, den 31.03.2020, 20:38 + schrieb Jonas Schäfer:
> This message constitutes notice of a Last Call for comments on
> XEP-0280.
>
> Title: Message Carbons
> Abstract:
> In order to keep all IM clients for a user engaged in a conversation,
> outbound messages are carbon-copied to all
Am Donnerstag, den 09.07.2020, 11:27 +0100 schrieb Dave Cridland:
> On Wed, 8 Jul 2020 at 12:44, Ruslan N. Marchenko
> wrote:
> > Am Dienstag, den 07.07.2020, 10:55 +0100 schrieb Dave Cridland:
> > > If Alice connects and authenticates Bob via some means, and Bob
> > &g
Am Dienstag, den 07.07.2020, 10:55 +0100 schrieb Dave Cridland:
> On Mon, 6 Jul 2020 at 15:41, Ruslan N. Marchenko
> wrote:
> > Am Montag, den 06.07.2020, 16:20 +0200 schrieb Ruslan N. Marchenko:
> > > Am Montag, den 06.07.2020, 13:19 +0100 schrieb Dave Cridland:
> > &
Am Montag, den 06.07.2020, 16:20 +0200 schrieb Ruslan N. Marchenko:
> Am Montag, den 06.07.2020, 13:19 +0100 schrieb Dave Cridland:
> > On Mon, 6 Jul 2020 at 12:44, Ruslan N. Marchenko
> > wrote:
> > > Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland:
> >
Am Montag, den 06.07.2020, 13:19 +0100 schrieb Dave Cridland:
> On Mon, 6 Jul 2020 at 12:44, Ruslan N. Marchenko
> wrote:
> > Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland:
> > > On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko
> > > wrote:
> >
Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland:
> On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko
> wrote:
> > Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave Cridland:
> > > On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko
> > > wrote:
> >
Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave Cridland:
> On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko
> wrote:
> > Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave Cridland:
> > > On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko
> > >
Am Donnerstag, den 02.07.2020, 17:37 +0200 schrieb Florian Schmaus:
> On 7/2/20 1:26 PM, Ruslan N. Marchenko wrote:
> > Am Donnerstag, den 02.07.2020, 11:23 +0200 schrieb Florian Schmaus:
> > > I am not sure if this is a downgrade attack (at least a
Am Donnerstag, den 02.07.2020, 11:23 +0200 schrieb Florian Schmaus:
>
> I am not sure if this is a downgrade attack (at least a full-blown),
> or,
> if it is, if it. Without xep440 the client would have send 'p' in the
> case you described, with a channel-binding type not supported by the
>
Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave Cridland:
> On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko
> wrote:
> > Because Alice's authentication fails on this particualr conneciton?
> > So it may be not Alice after all speaking, despite what 'from'
> > t
Am Sonntag, den 14.06.2020, 13:05 + schrieb XEP Editor Pipeline:
> Version 0.1.0 of XEP-0440 (SASL Channel-Binding Type Capability) has
> been released.
>
> Abstract:
> This specification allows servers to annouce their supported SASL
> channel-binding types to clients.
>
This describes
Am Mittwoch, den 01.07.2020, 10:37 +0100 schrieb Dave Cridland:
> On Tue, 30 Jun 2020 at 17:59, Ruslan N. Marchenko
> wrote:
> > Am Dienstag, den 30.06.2020, 17:59 +0200 schrieb Jonas Schäfer:
> >
> > > Hi list,
> >
> > >
> >
> &
Am Dienstag, den 30.06.2020, 19:27 +0200 schrieb Holger Weiß:
> * Ruslan N. Marchenko [2020-06-30 18:58]:
> > Now if EXTERNAL fails - that means there's something wrong with the
> > certificates. And proposal to fail back to dialback means we want
> > to
> > tolerate ce
Am Dienstag, den 30.06.2020, 17:59 +0200 schrieb Jonas Schäfer:
> Hi list,
>
> (Editor hat on)
>
> On behalf of the Council, I’d like to bring this pull request to the
> attention
> of the community:
>
> https://github.com/xsf/xeps/pull/963
>
> Input from server operators specifically would
Am Dienstag, den 23.06.2020, 18:55 +0200 schrieb Jonas Schäfer:
> Hi everyone,
>
...
> 4a) PR#963: PR#963: XEP-0178: Clarify SASL-EXTERNAL specification
> when s2s
> auth fails
> URL: https://github.com/xsf/xeps/pull/963
> Abstract: A while back it was discussed that XEP-0178 (SASL-EXTERNAL)
>
Am Dienstag, den 21.04.2020, 10:44 + schrieb p...@bouah.net:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Quick Response
> Abstract:
> Quickly respond to automated messages.
>
I like the quick response thingy, reminds me of canned messages on
pebble. So
Am Dienstag, den 31.03.2020, 20:38 + schrieb Jonas Schäfer:
> This message constitutes notice of a Last Call for comments on
> XEP-0357.
>
> Title: Push Notifications
> Abstract:
> This specification defines a way for an XMPP servers to deliver
> information for use in push notifications to
Am Samstag, den 04.04.2020, 11:47 +0200 schrieb Philipp Hörist:
> Hi,
>
> Am Sa., 4. Apr. 2020 um 11:33 Uhr schrieb Ruslan N. Marchenko <
> m...@ruff.mobi>:
> > Thanks, that makes perfect sense to me as in my limited _mere p2p
> > conversation_ use case all those
Am Freitag, den 03.04.2020, 21:51 +0100 schrieb Matthew Wild:
> Hi folks,
>
> XEP-0313 is a well-established protocol at this point, but didn't yet
> make it to the next stage in the standards process. Time to fix that!
>
> I have made a final round of updates to incorporate the various
>
On Thu, Sep 05, 2019 at 12:58:53PM +0200, Philipp Hörist wrote:
> Am Do., 5. Sept. 2019 um 12:36 Uhr schrieb Ruslan N. Marchenko
> :
>
>
> > And in 0353 messages are body-less hence not
> eligible for carbons.
>
>
>
> bodyless is eligible for carbon
On Thu, Sep 05, 2019 at 12:42:23PM +0500, Andrew Nenakhov wrote:
> вт, 3 сент. 2019 г. в 23:18, Georg Lukas :
> >
> > Speaking of 0353 as is, it was also not designed for Carbons. I think we
> > should explicitly make use of Carbons (by similar means as with MAM), so
> > that we do not need
Am Dienstag, den 03.09.2019, 10:58 + schrieb Maxime “pep” Buquet:
> On September 3, 2019 10:55:18 AM UTC, Dave Cridland <
> d...@cridland.net> wrote:
> > Thanks for your snappy response.
> >
> > On Mon, 2 Sep 2019 at 18:13, Ruslan Marchenko wrote:
> >
> > > Hi,
> > >
> > > I've recently
Am Dienstag, den 27.02.2018, 15:37 -0700 schrieb Peter Saint-Andre:
> On 2/27/18 10:33 AM, Ruslan N. Marchenko wrote:
> > That actually touches a point which is nagging me each time I'm
> > looking
> > into implementation. Who is responsible for closing the session?
> >
Am Montag, den 26.02.2018, 19:21 -0700 schrieb Peter Saint-Andre:
>
> The idea there was to allow multiple files to be sent in a session;
> you
> wouldn't close the session if you want to send more files, so you
> would
> send the element defined in §8.1 instead. IMHO a good
> solution would be
Am Mittwoch, den 21.02.2018, 16:17 + schrieb Kevin Smith:
> On 21 Feb 2018, at 13:21, Jonas Wielicki wrote:
> >
> > On Mittwoch, 21. Februar 2018 11:57:56 CET Kevin Smith wrote:
> > > On 21 Feb 2018, at 09:41, Jonas Wielicki
> > > wrote:
> > > > On
On 28.12.2017 22:41, Ruslan N. Marchenko wrote:
On 28.12.2017 20:41, Lance Stout wrote:
Both sides locally terminated the session, so both sides should be in
the ENDED
state. Period. Full stop.
That is a perfectly legal sequence of actions to take, but this
particular
combination suggests
On 28.12.2017 20:41, Lance Stout wrote:
Both sides locally terminated the session, so both sides should be in the ENDED
state. Period. Full stop.
The fact that one side ended up getting an error response to their
session-terminate is irrelevant, because (as you quoted) when locally
On 29.11.2017 20:25, Ruslan N. Marchenko wrote:
On 29.11.2017 17:42, Jonas Wielicki wrote:
Daniel thinks that there are clients which can only do SI, but
doesn’t recall
any off the top of his head.
Telepathy-gabble for one supports only SI. I'm currently looking if i
can monkeypatch
On 29.11.2017 20:16, Jonas Wielicki (XSF Editor) wrote:
This message constitutes notice of a Last Call for comments on
XEP-0363.
Title: HTTP File Upload
Abstract:
This specification defines a protocol to request permissions from
another entity to upload a file to a specific path on an HTTP
On 07.12.2017 18:35, Jonas Wielicki (XSF Editor) wrote:
This message constitutes notice of a Last Call for comments on
XEP-0352.
Title: Client State Indication
Abstract:
This document defines a way for the client to indicate its
active/inactive state.
URL:
On 05.12.2017 10:39, Evgeny Khramtsov wrote:
Tue, 5 Dec 2017 08:30:38 +
Kevin Smith wrote:
2) New namespace: previous version payloads are allowed through, new
versions won’t be allowed through until the validator is updated
No, new namespaces are treated as
On 29.11.2017 17:42, Jonas Wielicki wrote:
Present: Dave (Chair), Kevin, Georg, Daniel, Sam
Minutes: Yours truly.
Chat logs: http://logs.xmpp.org/council/2017-11-29#15:55:08
...
2. Vote on deprecating XEP-0095 (Stream Initiation)
---
Sam did
On 18.11.2017 17:14, Philipp Hörist wrote:
Why would a server allow that if it has no use case and leads to
problems?
When a client sets the preferences the server replies with the full
pref list, this gives the server the possibility to refuse some entries.
The XEP also states
note that
On 05.11.2017 19:21, Ruslan N. Marchenko wrote:
Hi,
On 16.10.2017 20:38, Jonas Wielicki (XSF Editor) wrote:
5. Is the specification accurate and clearly written?
The first thing I stumbled upon while starting drafting implementation
is - empty result.
?
?
0?
Or perhaps even ?
Some more
On 14.11.2017 22:37, Sam Whited wrote:
What do the server devs here think?
To be fair this protocol is implemented in majority(?) of existing xmpp
server implementations so the burden is zero.
The question is rather - what is the future vision for this component
protocol? It considered as
On 09.11.2017 23:54, Arc Riley wrote:
On Thu, Nov 9, 2017 at 12:30 PM, Florian Schmaus > wrote:
Fact is, if you would implement a new XMPP server without xep114,
you would
miss a lot of fun.
I haven't run an XMPP component since the
Hi,
On 16.10.2017 20:38, Jonas Wielicki (XSF Editor) wrote:
This message constitutes notice of a Last Call for comments on
XEP-0313.
Abstract:
This document defines a protocol to query and control an archive of
messages stored on a server.
This Last Call begins today and shall end at the
On 26.03.2017 00:01, Timothée Jaussoin wrote:
Hi,
It seems that this pull request brought some interesting discussions.
I'll try to clarify my position regarding this pull request.
Le vendredi 24 mars 2017 à 17:03 +0100, Andreas Straub a écrit :
Hey all,
this topic has been discussed at
On 23.03.2017 14:18, Dave Cridland wrote:
On 22 March 2017 at 20:08, Ruslan N. Marchenko <m...@ruff.mobi> wrote:
On 22.03.2017 20:37, Sam Whited wrote:
On Wed, Mar 22, 2017 at 2:28 PM, Yann Leboulanger <aste...@lagaule.org>
wrote:
One nice feature we also don't have with bloc
On 22.03.2017 20:37, Sam Whited wrote:
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.
On 18.03.2017 11:16, Dave Cridland wrote:
On 18 March 2017 at 09:53, Florian Schmaus <f...@geekplace.eu> wrote:
On 18.03.2017 09:43, Dave Cridland wrote:
On 17 Mar 2017 21:52, "Ruslan N. Marchenko" <m...@ruff.mobi
<mailto:m...@ruff.mobi>> wrote:
On 11.02
On 11.02.2017 21:43, Florian Schmaus wrote:
It should be explicitly stated that the CSI state is *not* (because it
can not) restored after a stream resumption. I've created a PR to
address this: https://github.com/xsf/xeps/pull/402
Why *not* btw? Device may detect the connection is dropped (by
On 07.03.2017 12:31, Jonas Wielicki wrote:
I would like a rationale for why after going visible again, the session is
treated as before sending initial presence. This feels counter-intuitive to
me: I would expect all my contacts to see the presence I most recently sent to
those on my "visible
Hi,
I've been trying to find a registration of the
urn:xmpp:features:rosterver namespace and found it's only mentioned
once(!) in RFC6121 and nowhere else - namely neither in
https://xmpp.org/registrar/namespaces.html nor in
https://xmpp.org/registrar/stream-features.html registry.
Is it
On 28.02.2017 17:27, XMPP Extensions Editor wrote:
This message constitutes notice of a Last Call for comments on XEP-0186
(Invisible Command).
Abstract: This document specifies an XMPP protocol extension for user
invisibility.
URL: https://xmpp.org/extensions/xep-0186.html
This Last Call
Hi,
there's a typo in Example 8. Service discovery response - should have
reversed direction (to/from).
Regards,
Ruslan
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe:
On 24.02.2017 13:10, Michal Piotrowski wrote:
Maybe initial presence should also be wrapped up inside bind2?
This could be handy. On the other hand how should this interoperate
with RFC 6121 4.2.1. In this section it's "recommended" that the
client first get's roster from the server
On 23.02.2017 08:36, Sam Whited wrote:
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,
On 21.02.2017 22:00, Kim Alvefur wrote:
Hi,
On Tue, Feb 21, 2017 at 09:35:51PM +0100, Ruslan N. Marchenko wrote:
If I understand it right - in absence of 'to' attribute on c2s - the server
itself is assumed as a recipient - i.e. == .
No, the current account is assumed, so ...
In MAM case
Good evening,
In the examples across XEP-0313 the IQs are all to-less.
If I understand it right - in absence of 'to' attribute on c2s - the
server itself is assumed as a recipient - i.e. == to='example.org' id='1'/>.
In MAM case archiving node for the user is user's bare jid - hence
Good afternoon,
I'm preparing implementation of the mam and since there're very few
details in the XEP-0313 about actual archiving, mostly about querying -
i believe the archiving process is then left at the discretion of the
implementers.
Now, to avoid storing multiple copies of the
On Wed, Feb 15, 2017 at 11:39:33AM +0300, Evgeny Khramtsov wrote:
>
> But we don't have these tools. XMPP is a "niche" protocol,
>
Ok, so let's keep it niche protocol by generating standards for each and
every use case.
___
Standards mailing list
Info:
On 15.02.2017 08:26, Evgeny Khramtsov wrote:
Wed, 15 Feb 2017 08:21:39 +0100
"Ruslan N. Marchenko" <m...@ruff.mobi> wrote:
Well, high-load is always a "corner" case: a very few people need it.
That doesn't mean we should ignore it. For example, SIP folks never
ign
On 15.02.2017 04:24, Travis Burtrum wrote:
Really? How many ports do you have to open?
At least 3 - 25, 465, 587
I have port 25 for SMTP
Lucky you
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe:
On 15.02.2017 07:44, Evgeny Khramtsov wrote:
I'm not here to convince you using balancers or/and ssl offload, feel
free not to use them. The thing is load balancers exist and some people
want to use them for whatever reason.
Exactly and normally load-balancers are making balancing decision
On 14.02.2017 20:36, Evgeny Khramtsov wrote:
There is yet another use case: letting load balancers (haproxy, nginx,
etc) support tls themselves and route decrypted traffic to an XMPP
backend. Currently, haproxy and nginx don't support XMPP STARTTLS
(although a patch for nginx exists with
On 14.02.2017 15:25, Travis Burtrum wrote:
(airports, coffee shops etc), save roundtrips. And this is the maybe,
most TLS libs I've seen it's easier to establish a direct TLS connection
than xmpp's custom STARTTLS.
Maybe it's because I'm not using high-level abstraction libs but with
openssl
On Tue, Feb 14, 2017 at 02:19:57PM +0100, Michal Piotrowski wrote:
>
> Why, there's general case in error handling section:
>
> Stream management errors SHOULD be considered recoverable;
> however, misuse of stream management MAY result in termination of the
> stream.
>
>
>
On Tue, Feb 14, 2017 at 12:17:10PM +0100, Michal Piotrowski wrote:
> In XEP-0198 I didn't find any information what should happen if clients sends
> too high 'h' parameter.
>
> What should be the server response in this case? The safest is probably to
> close the stream with error indicating a
On Mon, Feb 13, 2017 at 03:55:13PM -0600, Sam Whited wrote:
> On Mon, Feb 13, 2017 at 3:43 PM, Ruslan N. Marchenko <m...@ruff.mobi> wrote:
> > I don't understand what do we need to hide here by summoning port 5223 from
> > the oblivion.
>
> This is another reason why I
On 13.02.2017 21:57, Travis Burtrum wrote:
On 02/13/2017 02:26 PM, Ruslan N. Marchenko wrote:
So security here will be just in the sense "all or nothing" -
either you pass through (non-paranoid) or not (paranoid).
That's not true though, there are firewalls in practice today that
On 13.02.2017 19:58, Travis Burtrum wrote:
Boy am I glad you missed the last call deadline by a day so I don't have
to address your concerns. :)
On 02/12/2017 11:03 AM, Sam Whited wrote:
A minor nitpick: The requirements section isn't really requirements,
it's the actual main content of the
On 09.02.2017 00:07, XMPP Extensions Editor wrote:
This message constitutes notice of a Last Call for comments on XEP-0280
(Message Carbons).
Abstract: In order to keep all IM clients for a user engaged in a conversation,
outbound messages are carbon-copied to all interested resources.
On 09.02.2017 00:07, XMPP Extensions Editor wrote:
This message constitutes notice of a Last Call for comments on XEP-0352 (Client
State Indication).
Abstract: This document defines a way for the client to indicate its
active/inactive state.
URL: http://xmpp.org/extensions/xep-0352.html
On 08.02.2017 21:42, Evgeny Khramtsov wrote:
Wed, 8 Feb 2017 20:06:19 +0100
"Ruslan N. Marchenko" <m...@ruff.mobi> wrote:
RFC restricts nowhere
binding process to this extension
Actually it does, Section 14.4:
14 is a namespace section, so apparently it defines na
Allow me to put my two cents
On 08.02.2017 09:53, Evgeny Khramtsov wrote:
Wed, 8 Feb 2017 08:19:17 +
Dave Cridland wrote:
Right, I understand, and largely agree. I might scribble a draft to
address this, by clarifying what we really meant here.
I see also two issues
87 matches
Mail list logo