jdev - 2024-06-19

base64 that is used in XMPP is just an encoding right? so essentially any other format that allows me to encode "stuff" (like pictures and videos and whatever encrypted things) into a format would work as an alternative. as long as its specified of course

hmm reading the RFC actually it seems that it would so maybe I will go ahead and do that

Base64's just a way of representing binary data in text.

(Roughly)

right makes sense. the thing i am reading talks about "blocks" so i am guessing its just the packets over the network

so probably same thing that xmpp can just support

The main thing XMPP can't support is \0, which has no valid XML encoding. Anything that is fine with that could be used instead of base64, but base64 is the most widely used standard for binary-in-text-streams..

Well, and XML.

(I realise you can encode the XML entities, just need to do so)

MattJ, nitpick: all ASCII control characters except whitespace are forbidden in XMPP character data (i.e. not encodable).

not just \0

XMPP? I said XML :)

well, both

XML 1.0 forbids them (XML 1.1 allows them, but XMPP is strictly based on XML 1.0)

Fair

It's just a discussion happened in another MUC earlier about switching XMPP to EXI in order to eliminate the need for base64. I think we have options before obtaining a sledgehammer to crack a nut.

Does exi eliminate the need for base64 ?

nobody knows, the spec is too dense

(though I think it in fact can)

I really doubt it does, why would it change the text content in tags

It would be weird if it allowed encoding invalid XML

am I confusing that with cbor where you can tell the library you're expecting binary and then you'll get the raw data, otherwise it'll wrap it around base64 for you (when the schema says it's base64)?

There are other actually good ways to transfer binary without trying to cram it into size-limited XMPP stanzas

sorry what is "exi" ?

But from talking to a few it seems like the Venn diagram of the "base64 bad" vs "using any other protocol to complement XMPP is bad" people is just a circle

Trung, Efficient XML Interchange, a binary encoding of XML: https://en.wikipedia.org/wiki/Efficient_XML_Interchange

oh thank you

> XML 1.0 forbids them (XML 1.1 allows them, but XMPP is strictly based on XML 1.0) Wait, XML1.1 allows them? As entities I guess?

moparisthebest: I agree with you, but we have so many cases where we're doing the base64 thing. AFAIK the only protocols stuck with this are us and smtp

Right, but regardless of encoding, when you are sending length-limited stanzas around it doesn't make sense to put big files in them ever

And we have plenty of actual good tools for the job of transferring big files... We should use them instead

anyone with security labels implementation experience, if i read this correctly in https://xmpp.org/extensions/xep-0258.html the difference between a restrictive catalog and an unrestrictive, is just the server operator beeing to lazy to add one item to the catalog which has no label (meaning the client can send a message without adding a label). i tempted to assume if a server operator want that he should always add the empty item to the catalog instead of writing code that implicitly adds this if its unrestricted and the empty item is missing

Kev might have some insights :)

You can have a restrictive catalogue that doesn't have an unlabeled label.

And if it's unrestrictive, you shouldn't require there to be an item with no label in order to allow messages without a label.

why Kev? whats the Use Case for the Admin to not add a empty item to the unrestrictive cataloge?

other than laziness

hmmm

maybe to allow clients to write messages which do not support security labels

hm yeah thats a pretty good reason

hm no .. if its unrestrictive the server does anyway accept message without label

im back to, there is no reason for the admin to not add that item