XSF Discussion - 2020-05-03

  1. Yagiza

    Hello!

  2. Yagiza

    I have some questions about latest version of OMEMO implementation.

  3. Yagiza

    I tried to ask in jdev@conference.jabber.org but after more than 24 hours of waiting got no answer.

  4. Yagiza

    Can anyone here help me?

  5. Yagiza

    Or should I ask in Standards mailing list?

  6. jonas’

    Yagiza, that room is deprecated

  7. jonas’

    check out xmpp:jdev@muc.xmpp.org?join instead

  8. Yagiza

    Ok

  9. 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 ✎

  10. 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 ✏

  11. 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?

  12. flow

    not really nice but probably better than people getting the feeling being ignored there

  13. MattJ

    Automatically send invites to the new room?

  14. 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.

  15. jonas’

    so I’m not comfortable with running a bot there

  16. 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 :)

  17. MattJ

    And sure, an array of strings (lines) is a potential sane API for that

  18. MattJ

    An actual multiline string is equally sane if you have a standard line ending sequence for the current platform

  19. !XSF_Martin

    The dh key issue should be solved once jabber.org is migrated to prosody. 😃

  20. 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

  21. jonas’

    > Data provided for fields of type "text-multi" SHOULD NOT contain any newlines (the \n and \r characters).

  22. jonas’

    it’s a SHOULD NOT at least

  23. 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

  24. flow

    jonas’, right, not a MUST. and this is unrelated to the question why we shouldn't simply use text-multi for MAM IDs

  25. MattJ

    We set the subject iirc

  26. MattJ

    In old jdev

  27. 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

  28. MattJ

    Could do, yeah

  29. 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?

  30. Syndace

    flow: I guessed that clients set the xml:lang on stream level or on the <body>.

  31. Syndace

    So no good reason, could also set it on the message stanza

  32. jonas’

    best is to mix it up and use it inconsistently throughout the examples

  33. jonas’

    remind everyone about the inheritance rules

  34. flow

    Syndace, some of them probably due, but it is desireable that examples follow best practices, plus what jonas said ✎

  35. flow

    Syndace, some of them probably do, but it is desireable that examples follow best practices, plus what jonas said ✏

  36. Syndace

    That implies that best practice is setting it on the message stanza?

  37. flow

    Syndace, i'd say best practices is to avoid bytes on the wire when possible

  38. 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 ✎

  39. 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) ✏

  40. flow

    but for examples, on the stanza level is probably good enough

  41. Syndace

    Right. Will mix it up a bit :)

  42. 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*

  43. Syndace

    I think I do?

  44. jonas’

    that, too

  45. 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

  46. flow

    I think it is actually a bit confusing in the text

  47. jonas’

    and I doubt many check if it happens to coincide with the xml:lang they set on the s2s tsream

  48. 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."

  49. 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

  50. flow

    that makes it sound that you need to explicitly set xml:lang on the element to the readers unfamiliar with XML rules

  51. Syndace

    right, it forces you to set xml:lang on the elemenz

  52. flow

    which would lead to implementations emitting elements where it is explicitly set, and even worse implementations requiring it to be explicitly set ✎

  53. flow

    which would lead to implementations emitting elements where it is explicitly set, and even worse, implementations requiring it to be explicitly set ✏

  54. 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

  55. flow

    Syndace, are you talking about effective xml:lang on the body or explicitly set xml:lang on the body?

  56. Syndace

    Explicit

  57. flow

    no xep should ever depend on explicitly set inherited xml attributes values

  58. Syndace

    Actually, it doesn't even matter

  59. flow

    At least xmlns and xml:lang are inherited

  60. Syndace

    Is there a document I can refer to regarding xml:lang or do I repeat the rules myself

  61. 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

  62. flow

    Syndace, xml 1.0 § 2.12

  63. Syndace

    I agree that the current phrasing might be interpreted as requiring xml:lang, even though that wasn't my intention

  64. 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"

  65. Syndace

    > Syndace, xml 1.0 § 2.12 cool, thanks

  66. 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) :)

  67. Syndace

    Looking forward to where this XEP is going, I expect a bit of a wild ride :)

  68. 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

  69. marc

    Atm, I implemented it like in example 12 and 14

  70. Maranda

    I think the next thing I'll implement will be 409, a good portion of 386 is already done.