jdev - 2023-10-07

anyone have a handy resource on understanding rules regarding attribute namespacing? I can't seem to find anything and I recall a previous discussion where my assumptions were wrong

moparisthebest: check the standard? :)

https://www.w3.org/TR/xml-names/#scoping-defaulting

moparisthebest: for application in XMPP? As far as I know, attribute namespacing is hardly ever done in XMPP (I'm struggling to come up with an example). Although technically likely permissible, I fear for technical issues if they're applied, especially when they're needed to distinguish otherwise equally named attributes.

moparisthebest: basically, attribute namespaces are always explicit rnd never inherited. The default namespace of null (even on an element with a namespace) can conceptually be thought of as being namespaced by the element itself, but from a strict xmlns pov the attribute *does not* inherit the xmlns from the element it is on

pep.: Didn't you submit a XEP using attribute namespaces? I swear you did but can't find it now :'(

From the spec: > Default namespace declarations do not apply directly to attribute names Makes sense > the interpretation of unprefixed attributes is determined by the element on which they appear. What

The rest of the document seems to agree with the first quote, but that second one still confuses me

I'll just continue pretending unprefixed attributes live in the namespace the element they're on is in.

Unless it just means that, though they are in no namespace, whatever defines the element they are on also defines them?

Which obviously makes sense, but why confuse that with the "which namespace are they in" topic????

`<xmpp:xmpp xmlns:xmpp="xmpp"><xmpp:message xmpp:type="chat"><xmpp:body>please no<///>`

moparisthebest: yes, that is what it means

Unprefixed means the meaning it tied to the element and not to any namespace.

A prefixed attribute is defined by the namespace of the prefix instead

And very important unprefixed syntactically means no/null namespace

But if it is attached to an element that has a namespace, doesn't the attribute in some way belong to that namespace too?

Zash, I honestly can't come up with a way that pretending namespaces work that way break anything

other than querying for that-namespace vs null but if your users are aware of this...

moparisthebest, in the example above, <xmpp:xmpp xmlns:xmpp="xmpp"><xmpp:message xmpp:type="chat"/></xmpp:xmpp> is the same as <xmpp xmlns="xmpp" xmlns:xmpp="xmpp"><message xmpp:type="chat"/></xmpp> but different from <xmpp xmlns="xmpp"><message type="chat"/></xmpp>.

ah, that's right, thanks Link Mauve !

And libraries which do that (I’m only aware of Dino’s xmpp-vala) expose themselves to various exploits. ✏

I will explain with an example If you have a document with xhtml namespace and you see <a href> and later <link href> these two href are syntactically equivalent (null xmlns, name href, selected by same selectors) but semantically different (semantics define by the element they are found on) If you see rdf:about="" in any document it has a strictly *different* syntax than about="" without prefix no matter what element is is on and the semrntics of rdf:about are always the same no matter what element it is found on

but <foo xmlns="rdf" about=""/> ???

Zash: that about is both syntactically and semantically distinct from rdf:about

anyone aware of existing parsers in use in XMPP that limit individual stanzas to an upper limit on total # of elements and/or # of attributes?

moparisthebest: why does a question like that smell like you're on the trail of a new vulnerability?

also: libxml2 entity limits imposed as billion laughs mitigations might matter widely

wgreenhouse, it's our cue to grab what we can and go for a nice long walk in the woods

Zash: preferably reaching the trail via a Homer Simpson retreat into hedge

Actually I'm investigating writing an XML parser in rust that is zero copy and doesn't do any allocations, but I think that necessarily puts an upper bound on the number of elements and/or attributes I can support

So I'm looking for prior art as to: 1. If anyone has done this 2. What kind of limits would be sane (read: work) for real XMPP in the wild

I guess xml might not quite fit the serde data model, but going for something similar?

Does that mean you have to keep the original XML?

zero copy/no allocations and a DOM-based XML parser is a bad combination

but zero copy/no allocations and a SAX-based XML parser might work

I'd be very concerned about anything like an element count limit

> Actually I'm investigating writing an XML parser in rust that is zero copy and doesn't do any allocations, but I think that necessarily puts an upper bound on the number of elements and/or attributes I can support We certainly do depth limits. I don't remember if we do breadth limits or not.

😬

or does "no allocations" mean "no malloc() but oh so much stuff on the stack" ?

Usually

> or does "no allocations" mean "no malloc() but oh so much stuff on the stack" ? Well it means that parser doesn't allocate, the caller can supply it a buffer from the heap or the stack Like a server could allocate X kb per connection, and it would never grow, a single-connection client could certainly just use X kb from the stack and never allocate at all, which would be a good fit for an esp32 or an Atari 8-bit :) ↺

i doubt you can fit rust into an atari 8-bit machine

Of course you can

an average atari 8-bit rom (without bank switching) is 4KB ✏

Sure. Can write a very large program in 4k

wasn't rust pretty limited in target platforms still?

Zash: no, anything llvm can support is easy to do

techmetx11: runs fine on an Atari 800xl https://github.com/mrk-its/rust-mos

And anything gcc can support is basically ready also

How can we expect anyone to take XMPP seriously when you can connect to an IRC server from an 800xl but not an XMPP muc? It's the last thing preventing widespread adoption :D

judging from the assembly output from https://github.com/llvm-mos/llvm-mos

you'll have to do a lot of work, and even then, it would probably only fit your XML parser alone

before it fits up the ROM

moparisthebest, 4k? pfft, that's ludicrous amounts, try making a full XMPP client in 256 octets to really impress The Scene

Actually it's common to expand the 800xl's ram to 1mb and newer methods can expand it to 4mb

i said ROM though

isn't this running on a cartridge?

No, from hard drive

i see

now that sounds less impressive if you can just upgrade the hardware

>> Actually I'm investigating writing an XML parser in rust that is zero copy and doesn't do any allocations, but I think that necessarily puts an upper bound on the number of elements and/or attributes I can support > > > We certainly do depth limits. I don't remember if we do breadth limits or not. Kev: so do you malloc or realloc in response to input ever or no? ↺

oh well

In an ideal world we could allocate X per connection then never again, but I'm not sure how feasible this is in practice yet

> so do you malloc or realloc in response to input ever or no? Yes, We'll malloc fairly freely. I commend any effort to write zero-copy/alloc code, but I don't think it's the main bottleneck we face.

I accept that I may one day be proven wrong and regret my choices.

i wanna be proven wrong

>> so do you malloc or realloc in response to input ever or no? > > > Yes, We'll malloc fairly freely. I commend any effort to write zero-copy/alloc code, but I don't think it's the main bottleneck we face. I agree with you, this is at a "hey I wonder..." stage right now :) ↺

esp32 xmppager

what about XMPP client in a CD

moparisthebest, 0463

The return of the Linux Live CD, now without Pidgin?

I went back to 466 but not 463 -.- thanks pep. ! There's your attribute namespaces in XMPP example Guus https://xmpp.org/extensions/xep-0463.html#example-2

pep.: Minidom doesn't support attribute namespaces right?

Not yet I think? But it's definitely planned(tm)

>> Yes, We'll malloc fairly freely. I commend any effort to write zero-copy/alloc code, but I don't think it's the main bottleneck we face. > I agree with you, this is at a "hey I wonder..." stage right now :) BTW, when I say 'we', I mean my projects, rather than trying to speak for other people.