Hi,
Am 26. April 2019 um 19:29 Uhr + schrieb Daniel Gultsch:
> the XEP describes a comparatively sane approach for implementing OTR
> over XMPP (including message hints, tearing the session down on
> reconnect) To my knowledge the few clients that implemented those
> 'best practices' have
Hi,
XEP-0364 describes the current use of OTR encryption. It has been
deferred after inactivity. As it is an informational XEP that (to my
knowledge) correctly describes how OTR is currently used, can it be
moved by Council to Active?
Marvin
--
Blog: https://mg.guelker.eu
Am 09. März 2018 um 11:16 Uhr -0600 schrieb Sam Whited:
> On Fri, Mar 9, 2018, at 10:53, Georg Lukas wrote:
> > as part of Easy XMPP I wanted to have a way to completely migrate from
> > one account to another, or to be able to move a subset of your contacts
> > to another (local) JID.
>
> What
Am 09. Januar 2018 um 07:39 Uhr +0100 schrieb Daniel Gultsch:
> It's more important to
> have the tools than to bikeshed about how to use them.
Thanks. First hammer the nail in, and then think where it should have
gone. Nice idea.
To return from personal argumenting to more useful one, the
This is an interesting approach. Specifying the markup completely
externally would not have occured to me, but is a really cool idea.
Some notes:
§4.1 has:
> The start and end attributes define the range at which the span is
> applied. They are in units of unicode code points in the character
>
Am 06. November 2017 um 21:19 Uhr +0100 schrieb Daniel Gultsch
:
> It's probably more helpful if people comment on the actual XEP in
> regards to specific rules or wording in the XEP.
Read my message again. I have done that (commenting on wording with
regard to terminal
Am 06. November 2017 um 15:29 Uhr -0600 schrieb Sam Whited :
> > Not using something XML-based in a XEP's format
> > also creates a precedence case from which we don't know where else it
> > will come back at us when other XEPs are made.
>
> I didn't understand this, sorry,
The XEP defines requirements like "MUST be displayed in italics" (§6.5)
or "MUST be displayed with a horizontal line through the middle (strike
through)" (§6.6) that immediately map to the user interface and are not
possible to implement in a terminal client on most terminal emulators. I
don't see
Am 29. October 2017 um 12:59 Uhr + schrieb Sam Whited :
> In retrospect my example was poor. I need to know *why* this is helpful. What
> do you do with the formatting? How is it helpful?
Now, that depends on what is actually explained. If for example there's
some kind of
Am 28. October 2017 um 13:25 Uhr -0500 schrieb Sam Whited :
> To carry forward the formatting discussion, I'd like to collect some use
> cases from the community.
When I explain complex things to people, it's occasionally helpful to
colourise parts of the message differently;
On Sat, Feb 25, 2017 at 09:42:10AM +0100, Marvin Gülker wrote:
> However, it appears there's a number of XEPs on xmpp.org/extensions
> whose PDF files have no Table of Contents, albeit the HTML versions
> have.
I looked into this problem a little more, and it appears that the
Makefile
Hi,
I am sort of a paper person and thus usually prefer the PDF variant of
the XEPs over the HTML one. However, it appears there's a number of XEPs
on xmpp.org/extensions whose PDF files have no Table of Contents, albeit
the HTML versions have. Examples are:
* XEP-0124
* XEP-0131
* XEP-0136
*
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
Hi,
On Mon, Feb 06, 2017 at 04:46:58PM -0700, Peter Saint-Andre wrote:
> RFC 6120 author here. :-)
Great! :-)
> Note that the order of features matters. In the Bind2 proposal, the order is
> this:
I have to disagree. RFC 6120, section 4.3.2 says this, though it is
marked as an Implementation
On Mon, Feb 06, 2017 at 06:09:50PM +0300, Evgeny Khramtsov wrote:
> Mon, 6 Feb 2017 14:57:10 +
> Kevin Smith wrote:
>
> > Not really, that’s just how extensions work.
>
> I disagree. Extensions should extend, not replace, the RFC. Replacing
> RFCs by XEPs is some new
On Mon, Feb 06, 2017 at 03:25:15PM +0300, Evgeny Khramtsov wrote:
> I guess that's your opinion? Or where is it stated in the RFC? xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> is a mandatory-to-negotiate
> feature (at least if included), thus, clients MUST NOT ignore it.
I tend to agree with this.
On Fri, Dec 30, 2016 at 02:22:11PM +0100, Tobias Markmann wrote:
> > We need to aggressively address the spam problem.
>
> Indeed. Proposed solutions I've heard about so far are mostly requiring
> captcha on first contact or reputation systems. I think end-to-end captchas
> could result in a very
17 matches
Mail list logo