XSF Discussion - 2024-08-30

When you are a XSF member and have not voted yet in the current application period then please take some time and talk to memberbot. Thanka

Is the assumption correct that filled out fields of data forms (XEP-0004) always have a value (or do not exist)?

Can you expand "always have a value" and "do not exist"?

Where/when? On the wire?

When submitting a form, would something like this be valid? ``` <field type='text-private' var='password'> <value></value> </field> ```

`<!-- nothing -->` vs `<field/>` vs `<field><value/></field>` ?

(to remove a password, in this example)

Well that's an empty string, as far as the form is concerned

In MUC config forms, it's allowed to send only the 'delta' of a room config form.

In the case of a password, it would make sense for this to remove the password

I think that makes it required for a field to be in the form, and explicitly have a no-data value element, to 'unset' something (like removing all admins from a MUC)

(IIRC Prosody once had a bug around this, and would require users to supply an empty password to join the MUC)

All this has been discussed before, and all of it will be discussed again, and again, and again....

Well, I will point out that Guus has been helpfully submitting PRs for improving these kinds of things so hopefully some of them won't need to be discussed again... :)

Yay

I think at least with MUC it makes sense for absent `<field/>` to imply that whatever the current values were are kept.

Zash, that's explicitly defined in XEP-0045, yes.

that does take away 'not submitting a field' as an option to 'unset' a field value though.

Does that imply that there's no other manner to 'unset' a field other than supplying an empty `value`?

or possibly a `field` without a `value` child element at all?

oh, even XEP-0004 says that 'missing' fields should imply that the values of those fields remain unchanged in https://xmpp.org/extensions/xep-0004.html#incomplete-submission-form-handling

is teh

is there an xep to transfer data to anotehr one? xD

https://xmpp.org/extensions/xep-0227.html ?

> Does that imply that there's no other manner to 'unset' a field other than supplying an empty `value`? Empty value is empty string, no value is no value ↺

singpolyma: `<field><value></value></field>` vs. `<field><value/></field>` vs. `<field/>` ?

Yes

what's the distinction between the last two?

The first two are equivalent, the last two are different

Pretty subtle I guess <value/> is basically like there is a value and it is NULL whereas the last is no value

(per XML, I haven't consulted XEP-0004)

Oh, MattJ is right ignore me

<value/> is still empty string value

This isn't exactly an answer, because I think the XEP doesn't provide one, however in one unrelated paragraph it does say "the XML character data of the <value/> element MAY be null"

I assume it means empty == null, rather than literally the characters "null"

There is nowhere I can see that says that omitting the <value/> element implies a null value, or that null values (as something different to empty values) are supported

In the specific case of a password, the empty string seems fine to use as a null value.

Also is there a difference between `<field type="boolean"/>` and `<field type="boolean"><value>0</value></field>` ?

MattJ: well null is just a way one might think of it in some programming languages. No value isn't strictly speaking "a null value" but rather... No value ✏

My assumption is that most software implementations will expect a field to have a value-child element. Introducing a change to the XEP that says 'Do not provide a `value` element to unset the field' may be bad for backwards compatibility.

Sure, I agree "null" can have multiple interpretations. Which is why I think the "null" in the XEP is meant to mean "empty", rather than "no value", and that "no value" is not supported.

You think omitting <value/> is invalid?

Invalid is a strong word, but I do think it is not defined by the standard

It's not explicitly forbidden, but that is more likely due to oversight

Are you trying to say that it should have been forbidden?

I think it's needed. As it is how you specify no value

The XEP and the data model it defines has no concept of "no value" (I'd be happy to be proven wrong)

I'm not arguing whether it should or shouldn't have the concept of "no value", just saying that right now it definitely does not

So if there is a list-multi and the user selects zero items for example seems like a clear case where I would expect <value/> to be omitted

According to the XEP, choosing no items is also not allowed :)

list-multi: "A form-submitting entity chooses one or more items from among the options presented by the form-processing entity"

I'm honestly not sure what other than "I submitted a field with no value" submitted a field without a value could mean

singpolyma, I think the particular case of boolean, the default value is false, so *if* an implementation can handle absent value, it would default to false.

Again, not saying that's a good thing, but there it is, the standard

Ugh. Really? So list-multi is always required? :/

I suspect it's not, since there is also the separate concept of "required"

But then you would have to not include the list-multi field on submission if no items were selected, and that conflicts with the "not submitted == leave unchanged" logic

the latter is not unheard of, though

Right. Omitting the field is a seperate thing from requiring it to be filled out

Ultimately the backend will need to deal with whatever random XML gets thrown at it somehow (at least by producing an error or similar) so it's not *super* troubling. But it does seem like a weird way for the spec to be

oh super, XEP-0004 is final.

it is very final

It also doesn't do much by itself though. Always needs to be wrapped in another xep

but the parser code is reused between those XEPs

I believe that the XEP benefits from explicit wording, but as it's (very) final, there's only so much that we can do. What about adding a section that describes that prior to reaching 'final' state, the XEP didn't explicitly define fields that have an empty (`<field><value/></field>` or `<field><value></value></field>`) or no value (`<field/>`), and that implementations SHOULD expect any of these to represent the absence of a (non-empty) value?

Something like that, yes

" represent the removal/unsetting of a value" maybe

I think the answer is that it's up to implementations to do something sensible based on the context, but to highlight that this XEP does not standardize a way to differentiate between "empty" and "no value".

For example, an empty password field and a password field with no value should obviously be handled the same

But there may be cases where the difference matters, and this XEP doesn't support those use cases (other XEPs could potentially clarify it if they need to)

Yes. I think it's up to other xeps to specify their semantics.

> 3.6 Setting empty or no values > > As specified in the previous section, the values of the omitted fields SHOULD keep their current value. From this, it follows that 'unsetting' a field value requires a request to contain a <field/> element. > > This XEP does not standardize a way to differentiate between an "empty" and "no" value. Unless other XEPs explicitly define these semantics, implementations can be expected to use a variety of representations, such as `<field><value/></field>` or `<field><value></value></field>` or `<field/>` to signal the absence of a (non-empty) value.

My suggestion to add to XEP-0004 - but I've been struggling with the wording.

"add to XEP-0004" is not something you can do, procedurally.

Note your first two examples are just the same thing twice

There are only two variants not three

yes, please do not mention two equivalent physical XML representations

that only causes confusion

C14n?!

I think I can add to the XEP, given this from 0001: > Note: Once an XMPP Extension Protocol has been advanced to a status of Final, every effort shall be made to limit the scope of modifications; in particular, backwards-incompatible changes shall not be made. However, limited modifications may be made as long as they are optional, backwards-compatible extensions rather than modifications to the core protocol itself. Therefore, a Final protocol is safe for deployment in mission-critical applications.

The text that I'm adding doesn't (intend to) add new definitions. It merely documents consequences of what is the current final spec.

Wow. Even optional extensions are allowed in final? TIL

Some often act like those aren't allowed even in experimental without a namespace bump. And obviously no namespace bumps for final

well

some people argue that adding elements is not backwards compatible

i mean it would be pretty silly if clarifications were not allowed no?

> some people argue that adding elements is not backwards compatible 🙄 ↺

Unless someone raises concerns, I'm going to submit this text (without the equivalent XML snippet) as a change.

Change "no" to "absent" (I think that makes the meaning a bit clearer)

ack

Or someone somewhere will assume that "no" is the opposite of "yes" and they map to false and true :)

https://github.com/xsf/xeps/pull/1387

Wait, doesn't that PR change things significantly?

I grant it doesn't use normative language, but I think saying that implementations are expected to do something isn't what you mean.

Does it?

Words are hard

I read what you're saying as that someone submitting a form could use <field><value/></field> or <field/>, and that these both mean that there is no value.

I don't know how to express what you're trying to in an unambiguous way, though.

I tried rewording but my first couple of attempts were worse

That's why I used the awkward "to signal the absence of a (non-empty) value" fragment

I'm very open to improvements to this text

How about: > This XEP does not standardize a way to differentiate between an "empty" and "absent" value. Absent further clarification in specifications using this one, there is no way to signal an absent value, as <field><value/></field> represents a present but empty value, and <field/> is not generally legal. ? Is that what you're trying to say? ✏

Isn't that more normative than my original text?

Possibly adding an "It is strongly suggested that specifications using this one define how/whether absent values are represented"

> Isn't that more normative than my original text? I don't believe so, it's just stating three things that are currently true by normative text.

What I like about your text is that it dissuades usage of `<field/>` which is suspect to be incompatible with many implementations.

Is it not 'legal' though?

Kev, well no, you can't have a specification using '4 suddenly make absent elements legal.

> , well no, you can't have a specification using '4 suddenly make absent elements legal. Sure you can. "An empty string value is to be treated as the removal of the previous value". Done.

that's completely different from what I intended to write

but I lack energy for this right now

> Is it not 'legal' though? You can't e.g. not include a value in a list-single, can you?

> that's completely different from what I intended to write I was not being deliberately obtuse, I don't think I understood your statement, then.

Matt explained earlier that -multi fields must contain at least one value, but I'm not sure if that's true for other types.

> Matt explained earlier that -multi fields must contain at least one value, but I'm not sure if that's true for other types. Well, that's enough for <field/> not to be generally legal, then, isn't it?

I feel that that's more word-play than true to the intention of the phrase :)

Kev, I don't blame you (which is why I wrote "what I intended to say" instead of "what I wrote". I assume my statement was somehow ambiguous, but I'm out of energy to debug language right now :))

> , I don't blame you (which is why I wrote "what I intended to say" instead of "what I wrote". I assume my statement was somehow ambiguous, but I'm out of energy to debug language right now :)) My text was certainly not intended to suggest that consuming specs should make legal some use of xep4 that is illegal in xep4 itself, if that's what you mean. ✏

Merely that because xep4 doesn't cover these cases, a consuming spec should spell out what's mean in that use.

My language is likely not ideal.

s/mean in that/meant in that/

I definitely don't think we should make it say that field without value is not legal. Unless it already says that, which I don't think it does (except implied in the list multi case maybe)

My text says it isn't *generally* legal, which is true because list-multi requires a value.

list-single requires a value too.

random shower thought of the day, can the public federated XMPP network be used to easily DDOS a target of the attacker's choice ?

say I want to attack bob.com:443, I can connect to all XMPP servers I know from $randomsubdomain.alice.com which will trigger them connecting back to me by looking up _xmpp-server._tcp.$randomsubdomain.alice.com which will return 1 record, bob.com port 443

I can connect X times each to Y servers and poor bob.com gets X*Y connections made to it from Y different servers ?

do any servers have any rate limiting, caching, backoff etc on a host/port target level ?

Doesn't that use equal resources for you too? You make as much connections to every sever as they do to your target

And for a Webserver, one single attempt from every xmpp server you happen to know. Isn't that that only a small hickup?

If anything we need something to deal with all the long gone or mispelled servers that there are always a ton of attempts to connect to all the time.

> Doesn't that use equal resources for you too? > You make as much connections to every sever as they do to your target not equal, and not without revealing your IP to the target which is easily blocked ↺

> And for a Webserver, one single attempt from every xmpp server you happen to know. Isn't that that only a small hickup? not a single attempt either, retries, can return 40 SRV records all pointing to the same IP+port etc etc ↺

> If anything we need something to deal with all the long gone or mispelled servers that there are always a ton of attempts to connect to all the time. why not both ? :) ↺

Hm. I don't think my server does retries. Will have to check what more dns records do