-
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?
-
jonas’
doesn't list-something imply that the options are fixed by the server?
-
pep.
Here they are, it's a list returned by the server to say what pubsub#type (now) it hosts
-
flow
Zash, hmm isn't idna punnycode and doesn't punnycode just encode unicode, and there is no unicode in foo@bar/baz
-
flow
not that I have all the encoding rules always in my head, so I very well be wrong here
-
flow
Zash, which error did you expect?
-
pep.
I'll leave text-multi. Maybe in a few years somebody will come up saying it was wrong all along..
-
jonas’
no, text-multi makes sense
-
jonas’
list-multi would imply <option/>
-
jonas’
and that doesn't make much sense
-
pep.
Also in here https://bouah.net/specs/pubsub-filter.html ?
-
flow
hmm didn't we had the text-multi vs. list-multi discussion also wrt to MAM ID queries?
-
pep.
(I should add an anchor on that example)
-
pep.
I'm curious because in 0004 it says text-mutli is a single string split
-
pep.
aiui
-
flow
pep., IIRC you are right
-
pep.
And here (both cases) it's multiple values
-
flow
text-multi is that unintuitive field type which is basically "text with multiple newlines"
-
flow
and not "multiple different values of text"
-
pep.
So what's "multiple different values of text"?
-
flow
list-multi
-
flow
see also xep313
-
pep.
Ok
-
Kev
list-multi if they're selections from a list.
-
flow
"selections from a list" in the broadest sense
-
Kev
And there isn't one if what you want is the ability to provide multiple values that aren't selections from a list.
-
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
-
flow
in xep313 we use list-multi to select from an unknown list of IDs
-
flow
also this note:
-
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.
-
Kev
Indeed.
-
pep.
hmm
-
pep.
Right because a client will use this form to reply right
-
flow
so what you want is list-multi + validate open
-
flow
so what you want is list-multi + validate open✎ -
pep.
Not in my case
-
flow
so what you probably want is list-multi + validate open ✏
-
pep.
My first example is just the server saying "that's all I support"
-
pep.
My first example is just the server saying "that's all I host"
-
pep.
And in the second, it's the client saying "I want to filter these"
-
pep.
So there's no response. A form isn't really necessary
-
pep.
But it's what commonly used I thought
-
pep.
Also it's the only way to add info into disco#info no? 0004 Alongside <feature/>s
-
flow
pep., I am sorry but I am a bit lost :/ which ProtoXEP are we talking about?
-
pep.
pubsub-ns. Which was rejected but I'm going to submit again on a different form (now that pubsub#type has been """clarified""")
-
pep.
I already have https://github.com/xsf/xeps/pull/1156 PR'd
-
pep.
Second one incoming
-
flow
is there a rendered version somewhere?
-
pep.
link in the PR
-
pep.
Also linked above
-
pep.
https://bouah.net/specs/pubsub-filter.html
-
flow
I tend to say that this should be list-multi instead of text-multi, if it helps
-
pep.
Thanks. I'm updatin git
-
flow
nit: I am not really happy with the usage of the term "blocked" (and allowed) here
-
pep.
What would you rather see?
-
flow
but it's about filtering, so it's tricky as the best you could probably do is "filter" and "filter-out"
-
flow
"filter" will always be ambigous, as it's not immediatly clear if the filter removes those elements or only allows those elements through✎ -
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 :/
-
pep.
(where it's more appropriate)
-
pep.
Hopefully the text clarifies it a bit
-
flow
"filter" will always be ambiguous, as it's not immediatly clear if the filter removes those elements or only allows those elements through ✏
-
pulkomandy
"include"/"exclude" ?
-
pep.
Then it's confusing for the following sister XEP I'd say? Should I use different terms nonetheless?
-
Zash
flow, ICU returns UIDNA_ERROR_DISALLOWED for @ and /
-
jonas’
idna2003 or idna2008? :)
-
Zash
2008
-
jonas’
python does 2003 IIRC
-
pep.
flow, updated with list-multi thanks
-
pep.
Also any clue about the TODO after the example? https://bouah.net/specs/pubsub-filter.html#example-1
-
flow
pep., I'd slightly favor "filter-type" and "filter-out-type" for pubsub-filter
-
Zash
Did anyone ever point at this vaguely related thing: https://xmpp.org/extensions/xep-0045.html#impl-service-traffic
-
pep.
Dunno if that's what should be used, but I'm thinking MUC could use something similar to pubsub#type indeed
-
pep.
(channel vs groupchats etc.. and others)
-
flow
pep., is the empty form of any value? if not, then forbid it?
-
pep.
It's equivalent to <field type='boolean' var='include-empty'><value>true</value></field> because I declare a default value in the spec
-
pep.
So it's of some value I guess
-
pep.
Isn't it
-
pep.
Can a list-multi field be empty btw
-
pep.
("no elements proposed")
-
flow
pep., so the empty field would only return pubsub items without type?
-
pep.
Yeah
-
flow
btw, I would also mandate return an error if both are set and not "ignore one"
-
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.
-
pep.
At the bare minimum I think it should be specified, so here it is.
-
pep.
I might change that later
-
flow
code *what* however they want? it appears that's always an issue
-
pep.
What's always an issue? You mean this comes back often? To error or not error?
-
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
-
pep.
I'll change it anyway. Not going to die on this hill :)
-
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
-
flow
but the receiving entity can not tell which case it is, so it should lean towards the safe side of erroring out
-
pep.
Well yes the receiving entity can tell since it's specified
-
flow
how can the receiving entity tell the potentially wrong assumptions of the sending entity?
-
flow
otoh, it's hard to come up with an example of such a wrong assumption in this case
-
pep.
Is <value></value> (or <value/>, they are equivalent right?) valid? To designate the empty value
-
pep.
(looking up XML Schemas..)
-
Zash
Empty string in most cases
-
pep.
Yeah empty string is good
-
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.”
-
pep.
It may need to be defined specifically in the schema? (with <xs:simpleType><xs:restriction base="xs:string"><xs:enumeration value=""/>//)
-
Zash
That is a thing I've seen in some places
-
pep.
Which 0004 doesn't have
-
pep.
There's an 'empty' type defined but it's not used for value
-
pep.
hmm. I guess I'll submit submit using this, and somebody will correct the XEP someday because their lib broke or sth :/
-
pep.
Unless anybody knows how to do that
-
pep.
flow, I updated the PR with your comments. Thanks! Still missing a change on allow/block.. not entirely sure what to do here
-
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
-
nav
Is anybody aware of any clients (mobile in particular, but also desktop) implementing XEP-0080 (User Location)?
-
nav
https://xmpp.org/extensions/xep-0080.html
-
nav
…or any similar XEP?
-
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.
-
nav
That way, you can have a JID representing a person or asset and track it via PEP (XEP-0080).
-
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.
-
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. 🙂