jdev - 2022-02-02

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?

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

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

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

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

Zash, which error did you expect?

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

no, text-multi makes sense

list-multi would imply <option/>

and that doesn't make much sense

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

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

(I should add an anchor on that example)

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

aiui

pep., IIRC you are right

And here (both cases) it's multiple values

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

and not "multiple different values of text"

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

list-multi

see also xep313

Ok

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

"selections from a list" in the broadest sense

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

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

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

also this note:

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.

Indeed.

hmm

Right because a client will use this form to reply right

so what you want is list-multi + validate open

Not in my case

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

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

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

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

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

But it's what commonly used I thought

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

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

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

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

Second one incoming

is there a rendered version somewhere?

link in the PR

Also linked above

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

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

Thanks. I'm updatin git

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

What would you rather see?

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

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 :/

(where it's more appropriate)

Hopefully the text clarifies it a bit

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

"include"/"exclude" ?

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

flow, ICU returns UIDNA_ERROR_DISALLOWED for @ and /

idna2003 or idna2008? :)

2008

python does 2003 IIRC

flow, updated with list-multi thanks

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

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

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

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

(channel vs groupchats etc.. and others)

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

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

So it's of some value I guess

Isn't it

Can a list-multi field be empty btw

("no elements proposed")

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

Yeah

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

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.

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

I might change that later

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

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

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

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

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

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

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

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

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

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

(looking up XML Schemas..)

Empty string in most cases

Yeah empty string is good

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

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

That is a thing I've seen in some places

Which 0004 doesn't have

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

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

Unless anybody knows how to do that

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

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

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

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

…or any similar XEP?

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.

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

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.

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