XSF Discussion - 2020-09-15

Some iteam members present? https://mail.jabber.org/pipermail/operators/ seems to be offline. At least I can't reach it.

Meh, once you complain out of a sudden it works again. :-/

mdosch, yeah, the presentation phenomenon ;)

jonas’> MattJ, note that XML forbids control characters, even in escaped form Do you have a reference for me?

I just tried to find the corresponding part via a quick look at the XML 1.0 spec, but failed. I very well believe that something like that could be in there

flow, https://www.w3.org/TR/REC-xml/#sec-references

"Character references" (i.e. &#nnn; escapes) are only allowed to represent legal characters

MattJ, "Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646"

not sure (yet) if this definition of "legal character" includes e.g. control characters

"Characters referred to using character references MUST match the production for Char."

Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]

ahh

so I guess everyhing that does not match this production, must be escaped via JSON escaping

Yes

although I could image that it could be disputed if "\u0007" is valid in JSON

but that's not our discussion :)

now i wonder if there are code points that are legal in XML 1.0 but have to be escaped using hex entity encoding

flow, depends on the context, for instance in attributes, U+0022 and U+0027 are both legal, but one of them has to be escaped.

U+003C in most contexts too of course.

yep, i mean besides the set of general etnities (amp, lt, gt, apos, quot)

flow, I don’t think so

Hmm, depending on the document encoding, characters outside of its representable set of Unicode?

For instance if your document is latin1, any character above that would have to be escaped.

encoding happens one layer below, shouldn't be relevant

Obviously irrelevant in the context of XMPP.

flow, does it?

it does

nevermind

the encoding, on the wire or within the file, is not relevant for the discussion how we shove JSON in XMPP's XML ✏

flow, because it is set to UTF-8 in XMPP, but e.g. if you use an XML editor and save as latin1, said editor would have to replace any codepoint above U+00FF with an escaped version of it, giving the exact same result as if it had been escaped previously.

Am I wrong?

What the character data represents is irrelevant in this case.

Link Mauve: JSON -A> XMPP -B> XML -C> wire

we are only talking about A and B here

Ok.

that the resulting XML in this chain is encoded using UTF-8 before being put on the wire is irrelevant for the discussion about what and how to escape JSON in XMPP's XML ✏

Well not so much, it can be considered irrelevant only because UTF-8 allows representing all legal characters in XML 1.0 in unescaped form, so only illegal characters (but legal in JSON) have to be taken care of. ✏

Link Mauve, but the set of illegal XML 1.0 characters does not depend on the encoding used to store the XML, right?

No, it doesn’t.

ahh double negation

not sure if in agreement or not ✏

It is an agreement. ^^

phew

:)

language!

(is hard)

something something langsec

Mid-month reminder to send your project news, articles and updates to the XMPP Newsletter on September! 💌️ https://github.com/xsf/xmpp.org/pull/787 ✏