Re: [Standards] Proposed XEP-0060 Changes

[Peter Saint-Andre]

On 12/21/21 2:54 AM, Florian Schmaus wrote:

On 16/12/2021 14.32, Melvin Keskin wrote:
Hi Melvin,


1. Should I add that as § 3.5 to XEP-0004 (after
https://xmpp.org/extensions/xep-0004.html#protocol-results)?
2. Should I change
https://github.com/xsf/xeps/pull/1126/files#diff-0ede34e71ae8ea7199b84fe09913b235f648e79c1549a055b3ddd90fee3211f8R3734 


  to that?


I fear it is up to you to read the sentiment on the list to determine if 
sufficient consensus has been reached to put in the effort of 
resubmitting an updated version.


In general the answer to this questions is 'yes', because it can not 
hurt to start another iteration. While this is burdensome, and sometimes 
maybe even unrewarding, for the one doing the work, it eventually helps 
to increase the quality.


Furthermore, I've made good experience with negatively phrased 
questions, as in "Does anyone oppose to those changes?", and the 
interpret silence as agreement or disinterest.


https://datatracker.ietf.org/doc/html/rfc7282 has some helpful 
suggestions on reaching consensus. :-)


Peter

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XEP-0060 Changes

[Florian Schmaus]

On 16/12/2021 14.32, Melvin Keskin wrote:
Hi Melvin,


1. Should I add that as § 3.5 to XEP-0004 (after
https://xmpp.org/extensions/xep-0004.html#protocol-results)?
2. Should I change
https://github.com/xsf/xeps/pull/1126/files#diff-0ede34e71ae8ea7199b84fe09913b235f648e79c1549a055b3ddd90fee3211f8R3734
  to that?


I fear it is up to you to read the sentiment on the list to determine if 
sufficient consensus has been reached to put in the effort of 
resubmitting an updated version.


In general the answer to this questions is 'yes', because it can not 
hurt to start another iteration. While this is burdensome, and sometimes 
maybe even unrewarding, for the one doing the work, it eventually helps 
to increase the quality.


Furthermore, I've made good experience with negatively phrased 
questions, as in "Does anyone oppose to those changes?", and the 
interpret silence as agreement or disinterest.


- Florian


OpenPGP_signature
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XEP-0060 Changes

[Marvin W]

Hi,

On 15.12.21 17:24, Florian Schmaus wrote:
> The receiving entity of an incomplete submission form SHOULD only
> process (e.g., apply) the submitted field
I don't think that description really works well in the general case.
What does it mean to not "process" a non-submitted field? In many cases
this is not an option and the only possible way to handle non-submitted
fields is to pick a suitable default value for that field (typically the
one from the form presented before).

How about:

The receiving entity of an incomplete submission form SHOULD assume the
*current* default value of the respective form for fields that are not
submitted. In case the form is used to change a configuration, this
often means the current configuration value.

The second sentence is only for clarification purposes, as this is
already specified for example in 0060 § 8.2.2 ("SHOULD contain the
current node configuration as the default values").

Marvin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XEP-0060 Changes

[Melvin Keskin]

Thanks for the constructive discussion! Editing XEP-0004 sounds good.

> Incomplete Submission Form Handling
> 
> Incomplete submission forms are forms of the type 'submit, where are
> all required fields are set, but some non-required fields are
> omitted.
> The receiving entity of an incomplete submission form SHOULD only
> process (e.g., apply) the submitted fields. If applicable, the values
> of the omitted fields keep their current value (often the "default"
> value found in the corresponding 'form' type form).

1. Should I add that as § 3.5 to XEP-0004 (after 
https://xmpp.org/extensions/xep-0004.html#protocol-results)?

> Note that the [rules for incomplete submission form handling apply 
> (XEP-0004 § 
> TODO)](
> https://xmpp.org/extensions/xep-0004.html#incomplete-submission-form-handling
> ).

2. Should I change 
https://github.com/xsf/xeps/pull/1126/files#diff-0ede34e71ae8ea7199b84fe09913b235f648e79c1549a055b3ddd90fee3211f8R3734
 to that?

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XEP-0060 Changes

[Florian Schmaus]

On 15/12/2021 17.33, Dave Cridland wrote:



On Wed, 15 Dec 2021 at 16:14, Florian Schmaus > wrote:


On 15/12/2021 15.41, Dave Cridland wrote:
 > For the benefit of others wanting context, this is XEP-0060 section
 > 8.2.4. The existing SHOULD in this section is probably wrong, in
as much
 > as it's either meaningless (to configure a node, obviously you
send the
 > form) or else egregious (if you pull the form and the node seems
to be
 > set right, why reconfigure it?).

+1

 > On Wed, 15 Dec 2021 at 04:38, Travis Burtrum mailto:tra...@burtrum.org>
 > >> wrote:
 >
 >       > The submitted configuration form MAY contain a subset of
possible
 >     configuration options. In that case, the service MUST only
change the
 >     submitted configuration options.
 >
 >
 > I don't think that text expresses what is actually intended. I think
 > what you want to say is that if a client doesn't provide all the
 > options, the server fills in the "missing" values from the
configuration
 > form defaults, and not global defaults or something.

No, I think this is not why the motivation and intention behind the
proposed change is. "Filling unspecified values with the configuration
form defaults" does not sound sensible, assuming that it means
unspecified values could potentially be reset to their initial default
values if they have been modified afterwards.


By "the configuration form defaults", I mean the defaults in the 
configuration form from 8.2.2, which "SHOULD" be the current node 
configuration values, and not any kind of global defaults.


So I think you're agreeing with me, aren't you?


Seems so! \o/ Although this might indicate that "defaults from the 
configuration" can be misleading. I believe "current configuration 
values" is clearer.


With that, we could potentially improve as follows:

---
Incomplete Submission Form Handling

Incomplete submission forms are forms of the type 'submit, where are all 
required fields are set, but some non-required fields are omitted. The 
receiving entity of an incomplete submission form SHOULD only process 
(e.g., apply) the submitted fields. If applicable, the values of the 
omitted fields keep their current value (often the "default" value found 
in the corresponding 'form' type form).

---

How is that?

- Florian


OpenPGP_signature
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XEP-0060 Changes

[Dave Cridland]

On Wed, 15 Dec 2021 at 16:14, Florian Schmaus  wrote:

> On 15/12/2021 15.41, Dave Cridland wrote:
> > For the benefit of others wanting context, this is XEP-0060 section
> > 8.2.4. The existing SHOULD in this section is probably wrong, in as much
> > as it's either meaningless (to configure a node, obviously you send the
> > form) or else egregious (if you pull the form and the node seems to be
> > set right, why reconfigure it?).
>
> +1
>
> > On Wed, 15 Dec 2021 at 04:38, Travis Burtrum  > > wrote:
> >
> >   > The submitted configuration form MAY contain a subset of possible
> > configuration options. In that case, the service MUST only change the
> > submitted configuration options.
> >
> >
> > I don't think that text expresses what is actually intended. I think
> > what you want to say is that if a client doesn't provide all the
> > options, the server fills in the "missing" values from the configuration
> > form defaults, and not global defaults or something.
>
> No, I think this is not why the motivation and intention behind the
> proposed change is. "Filling unspecified values with the configuration
> form defaults" does not sound sensible, assuming that it means
> unspecified values could potentially be reset to their initial default
> values if they have been modified afterwards.


By "the configuration form defaults", I mean the defaults in the
configuration form from 8.2.2, which "SHOULD" be the current node
configuration values, and not any kind of global defaults.

So I think you're agreeing with me, aren't you?

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XEP-0060 Changes

[Florian Schmaus]

On 15/12/2021 16.03, Dave Cridland wrote:
That said, I think such things are better discussed in XEP-0004, and not 
here.


Dito. Irregardless of the "MUST vs. SHOULD" discussion, I also feel that 
such a clarification should go into xep4. We have similar situations in 
other XEPs that use xep4 as building block, e.g., xep45. And I don't 
think that it is sensible to spam most xep4 using XEPs with the same 
clarification.


How about adding the following to xep4:

---
Incomplete Submission Form Handling

Incomplete submission forms are forms of the type 'submit, where are all 
required fields are set, but some non-required fields are omitted. The 
receiving entity of an incomplete submission form SHOULD only process 
(e.g., apply) the submitted fields.

---

Then we *could* add a short sentence linking to the new section of xep4 
to the affected XEPs, if we feel like this is necessary. For example, 
adding the following to xep60 § 8.2.4


Note that the [rules for incomplete submission form handling apply 
(XEP-0004 § 
TODO)](https://xmpp.org/extensions/xep-0004.html#incomplete-submission-form-handling).


- Florian


OpenPGP_signature
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XEP-0060 Changes

[Florian Schmaus]

On 15/12/2021 15.41, Dave Cridland wrote:
For the benefit of others wanting context, this is XEP-0060 section 
8.2.4. The existing SHOULD in this section is probably wrong, in as much 
as it's either meaningless (to configure a node, obviously you send the 
form) or else egregious (if you pull the form and the node seems to be 
set right, why reconfigure it?).


+1

On Wed, 15 Dec 2021 at 04:38, Travis Burtrum > wrote:


  > The submitted configuration form MAY contain a subset of possible
configuration options. In that case, the service MUST only change the
submitted configuration options.


I don't think that text expresses what is actually intended. I think 
what you want to say is that if a client doesn't provide all the 
options, the server fills in the "missing" values from the configuration 
form defaults, and not global defaults or something.


No, I think this is not why the motivation and intention behind the 
proposed change is. "Filling unspecified values with the configuration 
form defaults" does not sound sensible, assuming that it means 
unspecified values could potentially be reset to their initial default 
values if they have been modified afterwards.



- Florian


OpenPGP_signature
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XEP-0060 Changes

[Dave Cridland]

On Wed, 15 Dec 2021 at 14:51, Kevin Smith  wrote:

> On 15 Dec 2021, at 14:41, Dave Cridland  wrote:
> > So, summary: I'd replace the opening text to 8.2.4 with:
> >
> > "If the owner wishes to change the configuration, they submit a
> completed configuration form. The server MUST treat any fields not included
> as though they are supplied with the default values from the configuration
> form (see 8.2.2)."
> >
> > Honestly I think the MUST there is a bit overkill, but I think the rest
> is OK.
>
> I think what we’re trying to say is (not a prose suggestion): “Accept a
> form with missing fields, and process missing fields as if the client isn’t
> trying to modify them”, is that right?
>
>
That seems reasonable, yes. Although "but":


> I think a small amount of vagueness here is of value, because one might
> imagine a form where setting one field means another must have a value - a
> helpful server might autogenerate the second value when the first is
> enabled, but a MUST synthesise the fields as if they were specified
> prevents that.
>

I see what you're saying, but that implies that a boolean field has three
values, true, false, and not present. And if there's a default for that
boolean field, then that becomes a rathole into which I do not wish to
descend. Maybe this is all OK, though.

That said, I think such things are better discussed in XEP-0004, and not
here.


>
> /K
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XEP-0060 Changes

[Kevin Smith]

On 15 Dec 2021, at 14:41, Dave Cridland  wrote:
> So, summary: I'd replace the opening text to 8.2.4 with:
> 
> "If the owner wishes to change the configuration, they submit a completed 
> configuration form. The server MUST treat any fields not included as though 
> they are supplied with the default values from the configuration form (see 
> 8.2.2)."
> 
> Honestly I think the MUST there is a bit overkill, but I think the rest is OK.

I think what we’re trying to say is (not a prose suggestion): “Accept a form 
with missing fields, and process missing fields as if the client isn’t trying 
to modify them”, is that right?

I think a small amount of vagueness here is of value, because one might imagine 
a form where setting one field means another must have a value - a helpful 
server might autogenerate the second value when the first is enabled, but a 
MUST synthesise the fields as if they were specified prevents that.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XEP-0060 Changes

[Dave Cridland]

For the benefit of others wanting context, this is XEP-0060 section 8.2.4.
The existing SHOULD in this section is probably wrong, in as much as it's
either meaningless (to configure a node, obviously you send the form) or
else egregious (if you pull the form and the node seems to be set right,
why reconfigure it?).

On Wed, 15 Dec 2021 at 04:38, Travis Burtrum  wrote:

>  > The submitted configuration form MAY contain a subset of possible
> configuration options. In that case, the service MUST only change the
> submitted configuration options.
>
>
I don't think that text expresses what is actually intended. I think what
you want to say is that if a client doesn't provide all the options, the
server fills in the "missing" values from the configuration form
defaults, and not global defaults or something.

This is, oddly, not specified in XEP-0004, even though I suspect we all
think it's obvious. Not including the fields at all, however, is - and
therefore this first MAY is not required (and is stipulating a conformance
outside its remit).

Once you have that, then you process the form as 8.2.5.

That makes no stipulations on the server as to how a form is processed, and
whether setting one value will change another, etc, so far.


> The concern here is that adding a MUST where one didn't exist previously
> could make existing compliant implementations suddenly non-compliant.  I
> believe it was said in MUC discussions that prosody follows this anyway,
> can anyone chime in about other implementations they know about ?
>
>
Modulo the MUST being not quite right, I don't think this does actually
change anything.


> It was also proposed that this MUST could be changed to a SHOULD, which
> would get around the protocol-breaking, but I'm not sure it adds a lot
> of value, since, if you can't be sure what the service will do, then you
> can never submit just a subset of config options and hope for the best.
>
>
MUST->SHOULD doesn't change much as regards older servers doing something
different, sorry. SHOULD is not "MAYBE", but "MUST (unless you really think
you know better, and even then, you don't)".


> Any input is appreciated.


But that's not what it said on the form! (Sorry)

So, summary: I'd replace the opening text to 8.2.4 with:

"If the owner wishes to change the configuration, they submit a completed
configuration form. The server MUST treat any fields not included as though
they are supplied with the default values from the configuration form (see
8.2.2)."

Honestly I think the MUST there is a bit overkill, but I think the rest is
OK.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XEP-0060 Changes

[Tedd Sterr]

> The submitted configuration form MAY contain a subset of possible 
> configuration options. In that case, the service MUST only change the 
> submitted configuration options.

Here, the 'MUST' means the service has to change the submitted options (to the 
values given) and only those options (no others). As a 'SHOULD' it would mean 
the service is technically allowed to deviate from that (possibly changing 
other options, or amending values to fit constraints) if it has a good reason 
to do so; if a service has such a need, then submitting the full form won't 
change that need and it could still modify/omit values as it sees fit. (Is 
there a requirement the service MUST change all given options for a full form 
submission? If not, submitting a subset wouldn't change this.)

I think 'SHOULD' is okay in this case.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XEP-0060 Changes

[Ralph Meijer]

Hi,

I too think that MUST is too strong here, as it leaves no room for services to 
ignore or override certain values, e.g. for policy reasons. SHOULD would be 
adequate here, indicating that one should understand the full ramifications of 
deviating from the specified behavior.

--
ralphm


From: Travis Burtrum 
Sent: Wednesday, December 15, 2021 05:36
To: XMPP Standards
Subject: [Standards] Proposed XEP-0060 Changes

> Hi all,
>
> A change to XEP-0060 has been proposed: 
> https://github.com/xsf/xeps/pull/1126/files
>
> 2 out of 3 parts are editorial in nature, the one part that is a 
> potential concern takes the current sentence:
>
> > After receiving the configuration form, the owner SHOULD submit a 
> completed configuration form.
>
> And appends the following to it:
>
> > The submitted configuration form MAY contain a subset of possible 
> configuration options. In that case, the service MUST only change the 
> submitted configuration options.
>
> The concern here is that adding a MUST where one didn't exist previously 
> could make existing compliant implementations suddenly non-compliant.  I 
> believe it was said in MUC discussions that prosody follows this anyway, 
> can anyone chime in about other implementations they know about ?
>
> It was also proposed that this MUST could be changed to a SHOULD, which 
> would get around the protocol-breaking, but I'm not sure it adds a lot 
> of value, since, if you can't be sure what the service will do, then you 
> can never submit just a subset of config options and hope for the best.
>
> Any input is appreciated.
>
> Thanks much,
> Travis
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Proposed XEP-0060 Changes

[Travis Burtrum]

Hi all,

A change to XEP-0060 has been proposed: 
https://github.com/xsf/xeps/pull/1126/files


2 out of 3 parts are editorial in nature, the one part that is a 
potential concern takes the current sentence:


> After receiving the configuration form, the owner SHOULD submit a 
completed configuration form.


And appends the following to it:

> The submitted configuration form MAY contain a subset of possible 
configuration options. In that case, the service MUST only change the 
submitted configuration options.


The concern here is that adding a MUST where one didn't exist previously 
could make existing compliant implementations suddenly non-compliant.  I 
believe it was said in MUC discussions that prosody follows this anyway, 
can anyone chime in about other implementations they know about ?


It was also proposed that this MUST could be changed to a SHOULD, which 
would get around the protocol-breaking, but I'm not sure it adds a lot 
of value, since, if you can't be sure what the service will do, then you 
can never submit just a subset of config options and hope for the best.


Any input is appreciated.

Thanks much,
Travis
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___