jdev - 2023-03-01

Is there any testing harness (big word) for JID validation?

Nothing universal. Prosody's tests are at https://hg.prosody.im/trunk/file/tip/spec/util_jid_spec.lua and it's been quite a while since anyone found bugs in it...

Wondering how we can have test suites accros languages

Defined input and output formats, not unheard of

I'm currently looking to have a proper RFC 6122 support in PHP

pep., MattJ: nothing universal and every time it is brought up someone NIHs a new format

Might as well just publish some CSV or whatever with inputs and expected results, something boringly simple and easy to parse - then people can figure out how to get that into whatever framework they use

MattJ: I might even have started but got bored when yet another custom format was proposed instead

"," isn't valid in any JID part?

I'd have two files, so that isn't an issue

I thought it was valid in resources, but haven't checked.

It is valid in resources.

You demonstrated at best it's valid in Prosody MUCs :P

Movim accepts it as well, as there is no proper validation at all :p

what would be super great for me is a "random UTF8 junk to valid resource part" converter. some legacy service allow control chars it seems. Or maybe it's slixmpp that is not permissive enough? Is "×͜× " a valid resource?

nicoco, resourceprep says "maybe"

nicoco, it isn’t.

(I just tried, and poezio showed no error… Will fix.)

nicoco, you might get some issue with multiple “random UTF-8 junk” mapping to the same resourcepart.

my "nickname cleaner" right now is `"".join(x for x in nickname if x in string.printable) + " [renamed by slidge]"`, but for this nickname for instance, it turns it to " [renamed by slidge]", which is not very satisfying

For instance, Link Mauve and Link Mauve do map to the same resource after resourceprep.

(In the xsf muc I suggested to discuss whether we should consider Google Season of Docs for writing XEPs. https://developers.google.com/season-of-docs/docs/get-started?hl=en xmpp:xsf@muc.xmpp.org?join )

and also, yes Link Mauve, you're right, I'm risking collisions

If the legacy protocol you map to considers those two different users, here be dragons.

well, they are 2 different users, but in MUCs, even non anonymous, the nickname is supposedly also a unique identifier

actually I was dropping by to ask whether it made any sense to use "XEP-0421: Anonymous unique occupant identifiers for MUCs" in *non*anonymous mucs.

nicoco, where everyone sees real JIDs? not much value in it, but I suppose it doesn't hurt for the server to do it anyway

> "," isn't valid in any JID part? Why wouldn't it be? Almost everything is allowed in localpart

in fact, AFAIU, none of the legacy services I map right now even have the concept of anonymous groups. but I suspect some clients are not going to allow retractions without it anyway. I'd rather avoid adding it if it doesn't make sense. more code = more trouble. ^^

reference to the C in CSV? it has quoting, so not a problem

I almost wrote TSV (which I prefer), but it's less of a standard

CSV is a standard because there are so many variants to choose from

is that the definition of a standard? something that you have many variants to choose from?

I think I'd just cry a tear and suggest JSON

I almost suggested JSON, but that's not ideal if you want to test various unicode things

Is that how ... was it flow? ended up with some newline-based custom format?

JSON is required to be utf8, no? So Unicode should be no issue

singpolyma, no, it's UTF-16

No, and the Prosody tests include invalid UTF-8

Zash: I think you're talking about the escape sequences?

So anything required to be valid unicode is not suitable, unless you add additional encoding

UTF16 encoded json is not a thing

Sure, escapes that use surrogate pairs and stuff. Depending on your JSON library.

Lua is obviously the best format :)

Binary safe, descendant of an actual data description format :)

MattJ: ah, so the tests assume utf8 decoder but contain raw binary?

What we did for the dhall tests was folders with input in one file and output in another

No format, just use the filesystem

Prosody's tests don't assume anything, as Lua isn't unicode-aware so you can put most things literally in strings. That's not always sensible due to editors and stuff, though.

So for some things we apply hex or base64

Soooooooooooooo we're doing another round of format bikeshedding?

Zash: no, we're just talking :) ✏

I'm just here because someone said commas might not be allowed in jid and I freaked out ;)

"Zash> Is that how ... was it flow? ended up with some newline-based custom format?" yeah fwiw I would do one line per entry, on two separate files. Not much parsing required, very little chance for confusion..

singpolyma, not what I said, I asked indeed because of CSV

pep., but how do you test jids with newlines???

Is that a thing?

no, but how do you verify that your library rejects it? :)

Indeed

or why not netstrings?

I mean, people can use whatever works for them :)

Hah! The thing I had started used XML

<?xml version="1.0" encoding="UTF-8"?> <tests type="invalid"> <test> <jid>node@/server</jid> </test> <test> <jid>@server</jid> </test> ...

and XSLT for turning into unit tests

seems like the obvious choice, given the standard this room is about

Means inventing a format and can't do invalid utf8 in the general case, but obviously it's an option

Why not just a jid per line and a valid.txt and an invalid.txt

https://github.com/igniterealtime/jxmpp/tree/master/jxmpp-strings-testframework/src/main/resources/xmpp-strings/jids

moparisthebest, I proposed that. And that means you can't test newlines in your jids

JIDs shouldn't have newlines ;)

But fine, seperate lines with \0

Or just use one file per input one per output and you don't need a format at all. So many options!

It's not just "valid" or "invalid" though - Prosody's tests extensively test correct splitting, which many clients/libraries have got wrong in the past

splitting? the 3 parts?

Rather than standard tests I'd rather see well tested libraries, ideally.

Most libraries right now accept almost any random crap in their jid "parser"

Isn't the goal here to have common test data and test all the libraries at the same time?

Exactly. That's part of the reason libraries aren't sufficiently tested... because without shared test cases, every project just writes their own and inevitably misses some

If they write any at all

Something like what exists for JSON and Markdown libraries ... but of course I couldn't those sites now

MattJ, fwiw, the valid jids are tested for proper splitting

in Smack?

no in jxmpp (which is used by Smack)

Right, sure

I'm not commenting on any individual implementation

I guess flow meant there is not need to test splitting separately?

Just saying I agree that a common set of test cases would be beneficial

ack

I brought up splitting because having a list of "invalid JIDs" and a list of "valid JIDs" is not sufficient for testing a JID parser

Anyway I'm happy with whatever people have. Maybe label tests so that they can be run separately?

and that's one of the solutions that was proposed

ahh ok, the list of valid JIDs in jxmpp corpus also consists of the expected splitted parts

Exactly. In what format? :)

the grammar is defined in https://github.com/igniterealtime/jxmpp/blob/master/jxmpp-strings-testframework/src/main/resources/xmpp-strings/jids/valid/main#L13-L20

basically using control chars to separate the parts

I guess that's easily convertible to another format anyway?

which yields the nice property that it's still a simple text file that can hold the corpus, while you do not need to escape antyhing

sure, transformations are possible, but I wonder if there is a better format. but I am happy to hear the ideas

the format jxmpp's jid corpus uses is trivially parsable

Is that the corpus?

Or just an example

the two files are the currently existing corpus

I see

I have some invalid JIDs scraped from openfire (courtesty of Guus) that I need to add

but since every JID is checked with 4 different "stringprep" implementations, it is a bit of work to add them to the corpus. because you first have to play protocol laywer and decide if its a valid jid or not, and then mask the non-conforming implementations

That doesn't seem to hard to use in xmpp-rs/jid

yeah yeah

it shouldn't be, I am sure there is a decent PEG parser for rust ✏

it's twice faster than nom.

(Sorry, private joke on #rust-fr)

pff, inside jokes :)

It's because pest, a peg parser in Rust, had a graph on their web page a while back showing how better it was than other Rust parsers, and it was totally bonkers. #Benchmarks

And the nom dev is a regular in #rust-fr so that was the joke

I would be happy of the jid corpus had a size where parsing speed would be of consideration :)

flow, is this correct? Corpus → Entry* Entry → Jid* | CommentLine*

Shouldn't Entry be Jid | CommentLine ? (without the *)

So that there is something to parse ✏

Since Corpus is already Entry*

is it currenlty simply saying that an entry consists of either potentially multiple Jid or CommentLine entries?

so the * suffix for Jid and CommentLine is not strictly required, but also technically not wrong

or am I missing something?

(it's been a while since I wrote this…)

Ah I thought * was 0+ not 1+

Yeah it's not wrong

hmm, wait, an entry consists of multiple jids or comments? ✏

I'd say at most one jid or at most one comment?

I mean, I think this is what it should be

I'm using afl to generate stanza/nonza test cases, could do the same for JIDs

https://gitlab.com/xmpp-rs/xmpp-rs/-/commit/7fece526332dfe4d32c1f1989349fbc17e6018c3 That's only the valid parser. Untested.

afk nao