jdev - 2022-02-02


  1. pep.

    Nobody cared much I guess, but https://xmpp.org/extensions/inbox/pubsub-ns.html#example-4 'text-multi' isn't correct here is it. Should be list-something?

  2. jonas’

    doesn't list-something imply that the options are fixed by the server?

  3. pep.

    Here they are, it's a list returned by the server to say what pubsub#type (now) it hosts

  4. flow

    Zash, hmm isn't idna punnycode and doesn't punnycode just encode unicode, and there is no unicode in foo@bar/baz

  5. flow

    not that I have all the encoding rules always in my head, so I very well be wrong here

  6. flow

    Zash, which error did you expect?

  7. pep.

    I'll leave text-multi. Maybe in a few years somebody will come up saying it was wrong all along..

  8. jonas’

    no, text-multi makes sense

  9. jonas’

    list-multi would imply <option/>

  10. jonas’

    and that doesn't make much sense

  11. pep.

    Also in here https://bouah.net/specs/pubsub-filter.html ?

  12. flow

    hmm didn't we had the text-multi vs. list-multi discussion also wrt to MAM ID queries?

  13. pep.

    (I should add an anchor on that example)

  14. pep.

    I'm curious because in 0004 it says text-mutli is a single string split

  15. pep.

    aiui

  16. flow

    pep., IIRC you are right

  17. pep.

    And here (both cases) it's multiple values

  18. flow

    text-multi is that unintuitive field type which is basically "text with multiple newlines"

  19. flow

    and not "multiple different values of text"

  20. pep.

    So what's "multiple different values of text"?

  21. flow

    list-multi

  22. flow

    see also xep313

  23. pep.

    Ok

  24. Kev

    list-multi if they're selections from a list.

  25. flow

    "selections from a list" in the broadest sense

  26. Kev

    And there isn't one if what you want is the ability to provide multiple values that aren't selections from a list.

  27. pep.

    They're not actual selections. I mean there's no UI associated, at least in the first case. There might be in the second, who knows

  28. flow

    in xep313 we use list-multi to select from an unknown list of IDs

  29. flow

    also this note:

  30. flow

    A special note about the 'ids' field: this field is of type 'list-multi' which typically is used to allow the client to select from a provided list of options. In this case the list of all possible ids MUST NOT be provided by the server, as it is likely to be extremely large. Instead the server MUST include a Data Forms Validation (XEP-0122) [8] <validate/> element that signals the list is open to arbitrary values provided by the client.

  31. Kev

    Indeed.

  32. pep.

    hmm

  33. pep.

    Right because a client will use this form to reply right

  34. flow

    so what you want is list-multi + validate open

  35. flow

    so what you want is list-multi + validate open

  36. pep.

    Not in my case

  37. flow

    so what you probably want is list-multi + validate open

  38. pep.

    My first example is just the server saying "that's all I support"

  39. pep.

    My first example is just the server saying "that's all I host"

  40. pep.

    And in the second, it's the client saying "I want to filter these"

  41. pep.

    So there's no response. A form isn't really necessary

  42. pep.

    But it's what commonly used I thought

  43. pep.

    Also it's the only way to add info into disco#info no? 0004 Alongside <feature/>s

  44. flow

    pep., I am sorry but I am a bit lost :/ which ProtoXEP are we talking about?

  45. pep.

    pubsub-ns. Which was rejected but I'm going to submit again on a different form (now that pubsub#type has been """clarified""")

  46. pep.

    I already have https://github.com/xsf/xeps/pull/1156 PR'd

  47. pep.

    Second one incoming

  48. flow

    is there a rendered version somewhere?

  49. pep.

    link in the PR

  50. pep.

    Also linked above

  51. pep.

    https://bouah.net/specs/pubsub-filter.html

  52. flow

    I tend to say that this should be list-multi instead of text-multi, if it helps

  53. pep.

    Thanks. I'm updatin git

  54. flow

    nit: I am not really happy with the usage of the term "blocked" (and allowed) here

  55. pep.

    What would you rather see?

  56. flow

    but it's about filtering, so it's tricky as the best you could probably do is "filter" and "filter-out"

  57. flow

    "filter" will always be ambigous, as it's not immediatly clear if the filter removes those elements or only allows those elements through

  58. pep.

    Especially since I'm reusing these terms in the following XEP that's about restricting the type of nodes that can be created on a service :/

  59. pep.

    (where it's more appropriate)

  60. pep.

    Hopefully the text clarifies it a bit

  61. flow

    "filter" will always be ambiguous, as it's not immediatly clear if the filter removes those elements or only allows those elements through

  62. pulkomandy

    "include"/"exclude" ?

  63. pep.

    Then it's confusing for the following sister XEP I'd say? Should I use different terms nonetheless?

  64. Zash

    flow, ICU returns UIDNA_ERROR_DISALLOWED for @ and /

  65. jonas’

    idna2003 or idna2008? :)

  66. Zash

    2008

  67. jonas’

    python does 2003 IIRC

  68. pep.

    flow, updated with list-multi thanks

  69. pep.

    Also any clue about the TODO after the example? https://bouah.net/specs/pubsub-filter.html#example-1

  70. flow

    pep., I'd slightly favor "filter-type" and "filter-out-type" for pubsub-filter

  71. Zash

    Did anyone ever point at this vaguely related thing: https://xmpp.org/extensions/xep-0045.html#impl-service-traffic

  72. pep.

    Dunno if that's what should be used, but I'm thinking MUC could use something similar to pubsub#type indeed

  73. pep.

    (channel vs groupchats etc.. and others)

  74. flow

    pep., is the empty form of any value? if not, then forbid it?

  75. pep.

    It's equivalent to <field type='boolean' var='include-empty'><value>true</value></field> because I declare a default value in the spec

  76. pep.

    So it's of some value I guess

  77. pep.

    Isn't it

  78. pep.

    Can a list-multi field be empty btw

  79. pep.

    ("no elements proposed")

  80. flow

    pep., so the empty field would only return pubsub items without type?

  81. pep.

    Yeah

  82. flow

    btw, I would also mandate return an error if both are set and not "ignore one"

  83. pep.

    hmm, I can see why (to prevent imlementations thinking they're doing something and not another), and I might add it, but there's also value in not returning an error I guess. To let implementations code it however they want.

  84. pep.

    At the bare minimum I think it should be specified, so here it is.

  85. pep.

    I might change that later

  86. flow

    code *what* however they want? it appears that's always an issue

  87. pep.

    What's always an issue? You mean this comes back often? To error or not error?

  88. pep.

    I don't know I'm not in people's minds. I know I can make my compiler prevent me from doing such a thing (including both), so this wording is fine by me even if it's less forbidding, maybe. I'm sorry for people who use a lesser language (/s but not really). Errors do happen nonetheless I agree

  89. pep.

    I'll change it anyway. Not going to die on this hill :)

  90. flow

    My line of thought is like: If an implementation includes both in the form, then in the best case it just wastes bandwith, but in the worst case it wrongly expects a certain semantic

  91. flow

    but the receiving entity can not tell which case it is, so it should lean towards the safe side of erroring out

  92. pep.

    Well yes the receiving entity can tell since it's specified

  93. flow

    how can the receiving entity tell the potentially wrong assumptions of the sending entity?

  94. flow

    otoh, it's hard to come up with an example of such a wrong assumption in this case

  95. pep.

    Is <value></value> (or <value/>, they are equivalent right?) valid? To designate the empty value

  96. pep.

    (looking up XML Schemas..)

  97. Zash

    Empty string in most cases

  98. pep.

    Yeah empty string is good

  99. pep.

    There's this in the spec: “Note: The empty string is not a member of the ·value space· of language. Some constructs which normally take language codes as their values, however, also allow the empty string. The attribute xml:lang defined by [XML] is one example; there, the empty string overrides a value which would otherwise be inherited, but without specifying a new value.”

  100. pep.

    It may need to be defined specifically in the schema? (with <xs:simpleType><xs:restriction base="xs:string"><xs:enumeration value=""/>//)

  101. Zash

    That is a thing I've seen in some places

  102. pep.

    Which 0004 doesn't have

  103. pep.

    There's an 'empty' type defined but it's not used for value

  104. pep.

    hmm. I guess I'll submit submit using this, and somebody will correct the XEP someday because their lib broke or sth :/

  105. pep.

    Unless anybody knows how to do that

  106. pep.

    flow, I updated the PR with your comments. Thanks! Still missing a change on allow/block.. not entirely sure what to do here

  107. pep.

    I explain in the XEP what they're supposed to be.. and if a lib wants to wrap them and make them clearer then that's what it'll do.. I was ok with include/excluse I guess

  108. nav

    Is anybody aware of any clients (mobile in particular, but also desktop) implementing XEP-0080 (User Location)?

  109. nav

    https://xmpp.org/extensions/xep-0080.html

  110. nav

    …or any similar XEP?

  111. nav

    The reason I'm asking is because I'm thinking it might be convenient to teach my webhooks component to recognise OsmAnd (https://osmand.net/) / Traccar (https://www.traccar.org/) position logging messages.

  112. nav

    That way, you can have a JID representing a person or asset and track it via PEP (XEP-0080).

  113. nav

    I am aware of Blabber.im and derivatives, which can interpret and display geo: URIs (https://datatracker.ietf.org/doc/html/rfc5870). That is great functionality for one-off positions, but not really for sending constant updates.

  114. nav

    Psi+ knows about PEP geolocation and shows much of the relevant info, which is great. If it displayed it in some kind of map widget à la Blabber.im that would be just ideal. 🙂