-
Yagiza
Hello!
-
Yagiza
I have some questions about latest version of OMEMO implementation.
-
Yagiza
I tried to ask in jdev@conference.jabber.org but after more than 24 hours of waiting got no answer.
-
Yagiza
Can anyone here help me?
-
Yagiza
Or should I ask in Standards mailing list?
-
jonas’
Yagiza, that room is deprecated
-
jonas’
check out xmpp:jdev@muc.xmpp.org?join instead
-
Yagiza
Ok
-
flow
MattJ> Therefore it is entirely reasonable for a library with a dataforms API to perform the newline splitting/joining itself I aggree, but that doesn't mean that the library should or even must loose the information about indvidual values✎ -
flow
MattJ> Therefore it is entirely reasonable for a library with a dataforms API to perform the newline splitting/joining itself I aggree, but that doesn't mean that the library should or even must loose the information about individual values ✏
-
flow
hmm maybe we should do something about jdev@conference.jabber.org. remove voice for non-members? autokick with a nice hint towards jdev@muc.xmpp.org?
-
flow
not really nice but probably better than people getting the feeling being ignored there
-
MattJ
Automatically send invites to the new room?
-
jonas’
I’d place a bot which auto-replies to anyone writing there with a link to the new room, but I can’t see what’s going on there due to the small dh key.
-
jonas’
so I’m not comfortable with running a bot there
-
MattJ
> "that doesn't mean the library should lose the information about the individual values" I agree they shouldn't be lost, but they aren't... they are just represented differently :)
-
MattJ
And sure, an array of strings (lines) is a potential sane API for that
-
MattJ
An actual multiline string is equally sane if you have a standard line ending sequence for the current platform
-
!XSF_Martin
The dh key issue should be solved once jabber.org is migrated to prosody. 😃
-
flow
I agree they shouldn't be lost, but they aren't... they are just represented differently :) They are lost as soon as there is a single value containing a newline, which is, as far as I can tell, not forbidden
-
jonas’
> Data provided for fields of type "text-multi" SHOULD NOT contain any newlines (the \n and \r characters).
-
jonas’
it’s a SHOULD NOT at least
-
flow
until we we have a nice bot or something in the old jdev@, we potentially should do something we can do right now, like changing the MUC configuration
-
flow
jonas’, right, not a MUST. and this is unrelated to the question why we shouldn't simply use text-multi for MAM IDs
-
MattJ
We set the subject iirc
-
MattJ
In old jdev
-
flow
so I wonder if we should prevent particpants for writing to the MUC? not really nice, but potentially better compared to them feeling ignored
-
MattJ
Could do, yeah
-
flow
Syndace, If I am not mistaken you are one of the authors of the quick response xep, right? If so, is there any reason why this examples declare xml:lang multiple times instead of simply once at the stanza level?
-
Syndace
flow: I guessed that clients set the xml:lang on stream level or on the <body>.
-
Syndace
So no good reason, could also set it on the message stanza
-
jonas’
best is to mix it up and use it inconsistently throughout the examples
-
jonas’
remind everyone about the inheritance rules
-
flow
Syndace, some of them probably due, but it is desireable that examples follow best practices, plus what jonas said✎ -
flow
Syndace, some of them probably do, but it is desireable that examples follow best practices, plus what jonas said ✏
-
Syndace
That implies that best practice is setting it on the message stanza?
-
flow
Syndace, i'd say best practices is to avoid bytes on the wire when possible
-
flow
in the real world, xml:lang is often defined at stream level so you wouldn't find it neither on the stanza or extension element level✎ -
flow
in the real world, xml:lang is often defined at stream level so you shouldn't find it neither on the stanza or extension element level (if it matches the stream level definition) ✏
-
flow
but for examples, on the stanza level is probably good enough
-
Syndace
Right. Will mix it up a bit :)
-
flow
after thinking a bit about it, am I actually not soo sure about the mixing. since xml:lang plays a key rule in the xep, it is maybe sensible to remind the reader of xml:lang inheritance rules and how the affect this particular protocol *in text*
-
Syndace
I think I do?
-
jonas’
that, too
-
jonas’
most of the time, you’ll find the attribute on the stanza though, since servers have to carry it over from the stream level when routing the stanza
-
flow
I think it is actually a bit confusing in the text
-
jonas’
and I doubt many check if it happens to coincide with the xml:lang they set on the s2s tsream
-
flow
"The xml:lang set on this element MUST mirror the xml:lang of the <body> included in the message stanza next to the <action> element."
-
Syndace
Maybe I don't repeat the inheritance rules, but I state that the body and the quick response elements must have the same xml:lang and that only one body is supported
-
flow
that makes it sound that you need to explicitly set xml:lang on the element to the readers unfamiliar with XML rules
-
Syndace
right, it forces you to set xml:lang on the elemenz
-
flow
which would lead to implementations emitting elements where it is explicitly set, and even worse implementations requiring it to be explicitly set✎ -
flow
which would lead to implementations emitting elements where it is explicitly set, and even worse, implementations requiring it to be explicitly set ✏
-
Syndace
I'm not 100% sure. "Mirroring" implies that if there is no xml:lang on the body, there is also no xml:lang on the action
-
flow
Syndace, are you talking about effective xml:lang on the body or explicitly set xml:lang on the body?
-
Syndace
Explicit
-
flow
no xep should ever depend on explicitly set inherited xml attributes values
-
Syndace
Actually, it doesn't even matter
-
flow
At least xmlns and xml:lang are inherited
-
Syndace
Is there a document I can refer to regarding xml:lang or do I repeat the rules myself
-
flow
I am currently trying to find out if the quick response xep does require explicitly set xml:lang in the extension element. I think it currently at least gives the impression
-
flow
Syndace, xml 1.0 § 2.12
-
Syndace
I agree that the current phrasing might be interpreted as requiring xml:lang, even though that wasn't my intention
-
Syndace
What I want to say is "the effective xml:lang of the action element MUST be equivalent to the effective xml:lang of the body"
-
Syndace
> Syndace, xml 1.0 § 2.12 cool, thanks
-
flow
Syndace, you are welcome, and thanks for the XEP (and that's from one as someone who loves data forms and ad-hoc commands) :)
-
Syndace
Looking forward to where this XEP is going, I expect a bit of a wild ride :)
-
marc
MattJ, Ge0rG: I modified 401 a bit and have also a first ejabberd implementation based on 389 http://dump.zapb.de/xeps/xep-0401.html#preauth-ibr
-
marc
Atm, I implemented it like in example 12 and 14
-
Maranda
I think the next thing I'll implement will be 409, a good portion of 386 is already done.