Re: [Standards] Council Minutes 2021-02-03

On Wed, 17 Feb 2021 at 21:07, Drew Varner wrote: > > But also XML C14N-based signing (such as XMLDSIG, which also happens in > the real world) would be broken by element reordering. > > Doesn’t the server adding or overriding a “from” in RFC6120 8.1.2.1 > already break XMLDSIG canonicalization?

Re: [Standards] Council Minutes 2021-02-03

On 2/17/21 5:28 PM, Jonas Schäfer wrote: In today’s council meeting, we decided on what we think is an improvement to the proposal in #1032 and which we are all OK with. You can observe the updated diff at: https://github.com/xsf/xeps/pull/1032/files Please provide feedback until the next

Re: [Standards] Council Minutes 2021-02-03

It doesn’t add the spaces. It just won’t detect them outside of SASL. I didn’t see a MUST on rejecting the spaces. Is that a requirement? > On Feb 17, 2021, at 11:01 AM, Sam Whited wrote: > > I believe this is only allowed between first-level elements elements per > RFC 6120 § 11.7, so it

Re: [Standards] Council Minutes 2021-02-03

In today’s council meeting, we decided on what we think is an improvement to the proposal in #1032 and which we are all OK with. You can observe the updated diff at: https://github.com/xsf/xeps/pull/1032/files The new changes are to be seen in (sorry for the linebreak):

Re: [Standards] Council Minutes 2021-02-03

On Wed, 17 Feb 2021 at 15:51, wrote: > Whitespace in between elements. This does not include the SASL stuff where > we cannot have it. > > > > > Does that break something? Seems insignificant to me. > > Well, and it might be. But I'm not sure how to tell without knowing the schema, unless

Re: [Standards] Council Minutes 2021-02-03

I believe this is only allowed between first-level elements elements per RFC 6120 § 11.7, so it will likely break something if used elsewhere (outside of nodes that are meant to contain text, that is). On Wed, Feb 17, 2021, at 10:50, drew.var...@ninefx.com wrote: > Whitespace in between elements.

Re: [Standards] Council Minutes 2021-02-03

Whitespace in between elements. This does not include the SASL stuff where we cannot have it. Does that break something? Seems insignificant to me. Also, it could change to > On Feb 17, 2021, at 10:06 AM, Dave Cridland wrote: > >  > > >> On Wed, 17 Feb 2021 at 14:49, Kevin Smith

Re: [Standards] Council Minutes 2021-02-03

On Wed, 17 Feb 2021 at 14:49, Kevin Smith wrote: > On 17 Feb 2021, at 14:44, Dave Cridland wrote: > > >> Attribute order, namespacing method (xmlns vs. prefix), and insignificant >> white space could also change. >> > > Aside from the latter - it's not clear to me how you tell if whitespace is

Re: [Standards] Council Minutes 2021-02-03

On 17 Feb 2021, at 14:44, Dave Cridland wrote: > > Attribute order, namespacing method (xmlns vs. prefix), and insignificant > white space could also change. > > Aside from the latter - it's not clear to me how you tell if whitespace is > truly insignificant - those are all OK, though

Re: [Standards] Council Minutes 2021-02-03

On Wed, 17 Feb 2021 at 13:31, wrote: > But you reorder different elements with anything that has a spec when > forwarding, is that right? > > > Correct. We may change the order in which child elements appear for > elements in our spec. Order among child elements of the same type (el name > +

Re: [Standards] Council Minutes 2021-02-03

> But you reorder different elements with anything that has a spec when > forwarding, is that right? Correct. We may change the order in which child elements appear for elements in our spec. Order among child elements of the same type (el name + namespace) is stable. Child elements of the same

Re: [Standards] Council Minutes 2021-02-03

On Tue, 16 Feb 2021 at 15:07, Drew Varner wrote: > > So, for example, XEP-0141 page elements could be reordered? > > No. The spec does not know about markup mini languages like XEP-0141, > XEP-0071, XEP-0393 and XEP-0394. Markup is validated at the client. Order > is maintained because the spec

Re: [Standards] Council Minutes 2021-02-03

I think this is the best place in the thread to reply with all my thoughts. Vote change to -0 (or +1 with additional fixes) instead of -1 inline. On Sonntag, 14. Februar 2021 21:12:17 CET Florian Schmaus wrote: > Eventually, this is a situation where we cannot avoid that somebody > needs to

Re: [Standards] Council Minutes 2021-02-03

> So, for example, XEP-0141 page elements could be reordered? No. The spec does not know about markup mini languages like XEP-0141, XEP-0071, XEP-0393 and XEP-0394. Markup is validated at the client. Order is maintained because the spec just encodes unknown XML into a struct that maintains

Re: [Standards] Council Minutes 2021-02-03

On Mon, 15 Feb 2021 at 19:03, Drew Varner wrote: > It will affect the stability of child node ordering when forwarding > stanzas if the model “knows” those elements. > > So, for example, XEP-0141 page elements could be reordered? That would seem to break things rather badly. Also, of course, any

Re: [Standards] Council Minutes 2021-02-03

It will affect the stability of child node ordering when forwarding stanzas if the model “knows” those elements. > On Feb 15, 2021, at 5:25 AM, Dave Cridland wrote: > > Somewhat off-topic, but does this have any implication on the stability of > ordering of child nodes in an XML tree when

Re: [Standards] Council Minutes 2021-02-03

Somewhat off-topic, but does this have any implication on the stability of ordering of child nodes in an XML tree when forwarding stanzas, or is this only when consuming or generating them? On Thu, 11 Feb 2021 at 18:11, Drew Varner wrote: > First time caller, long time listener. > > Some

Re: [Standards] Council Minutes 2021-02-03

It’s similar to P1’s implementation, in that it will pattern match the head of the child element list and pop a known child off and parse it. It’s a common approach in functional languages. https://github.com/processone/xmpp/blob/master/src/xep0004.erl#L152 Not sure how we’ll do it on the

Re: [Standards] Council Minutes 2021-02-03

On 2/11/21 7:09 PM, Drew Varner wrote: First time caller, long time listener. Some model-driven CODECs may not enforce nor detect order. P1’s model-based XMPP CODEC (https://github.com/processone/xmpp) does not enforce nor care about the order of the elements. ``` 2> ReportedFirst =

Re: [Standards] Council Minutes 2021-02-03

On 2/10/21 10:00 PM, Dave Cridland wrote: On Wed, 10 Feb 2021 at 20:22, Florian Schmaus > wrote: Since you asked: Smack relies on the ordering (in case a non-default form field type is used), since Smack needs to see the first to assign types to the

Re: [Standards] Council Minutes 2021-02-03

First time caller, long time listener. Some model-driven CODECs may not enforce nor detect order. P1’s model-based XMPP CODEC (https://github.com/processone/xmpp) does not enforce nor care about the order of the elements. ``` 2> ReportedFirst = <<"field-valuefield-value">>. <<"> 3>

Re: [Standards] Council Minutes 2021-02-03

On Wed, 10 Feb 2021 at 20:22, Florian Schmaus wrote: > Since you asked: Smack relies on the ordering (in case a non-default > form field type is used), since Smack needs to see the first > to assign types to the field while parsing the following s. > Right, so you're parsing using a SAX-style

Re: [Standards] Council Minutes 2021-02-03

On 2/10/21 6:54 PM, Dave Cridland wrote:> There's a few options. 1) We ignore the problem. 2) We note that there may exist implementations which rely on the ordering, but say receivers MUST NOT rely on ordering. 3) We note that there may exist implementations which rely on the ordering, and

Re: [Standards] Council Minutes 2021-02-03

On 2/10/21 5:28 PM, Jonas Schäfer wrote: Thanks for the minutes! On Mittwoch, 10. Februar 2021 16:58:30 CET Tedd Sterr wrote: 4b) PR #1032 (Data Forms Clarifications) - https://github.com/xsf/xeps/pull/1032 Jonas sees this as a massive normative change, rather than the clarification it

Re: [Standards] Council Minutes 2021-02-03

Am Mittwoch, dem 10.02.2021 um 19:37 +0100 schrieb Thilo Molitor: > > I cannot recall now where exactly it was but there was definitelly > > something about the order of the fields somewhere, because I > > remember > > adding a separate list with original key order to be able to use > > hashmap

Re: [Standards] Council Minutes 2021-02-03

> I cannot recall now where exactly it was but there was definitelly > something about the order of the fields somewhere, because I remember > adding a separate list with original key order to be able to use > hashmap while still preserving the order. But I really cannor recall > where it was

Re: [Standards] Council Minutes 2021-02-03

Am Mittwoch, dem 10.02.2021 um 17:28 +0100 schrieb Jonas Schäfer: > Thanks for the minutes! > > > As of now, I’m still -1. > > I want to elaborate the reason a little. Note that my -1 is solely > based on > the ordering requirement for , not the other commit in > that PR. > > I am not aware

Re: [Standards] Council Minutes 2021-02-03

On Wed, 10 Feb 2021 at 16:29, Jonas Schäfer wrote: > I am not aware of any place where we impose an ordering between elements > which > have *different* fully-qualified XML names (i.e. after namespace > expansion) [in > any Draft or significantly deployed standard]. Introducing this >

Re: [Standards] Council Minutes 2021-02-03

Thanks for the minutes! On Mittwoch, 10. Februar 2021 16:58:30 CET Tedd Sterr wrote: > 4b) PR #1032 (Data Forms Clarifications) - > https://github.com/xsf/xeps/pull/1032 Jonas sees this as a massive > normative change, rather than the clarification it claims to be; it > introduces a precedent of

[Standards] Council Minutes 2021-02-03

https://logs.xmpp.org/council/2021-02-03?p=h#2021-02-03-16c5bf8a7f6e3e9d 1) Roll Call Present: Daniel, Zash, Dave, Georg, Jonas 2) Agenda Bashing None. 3) Editor's Update * Proposed XMPP Extensions: - Implicit WebSocket Endpoints 4a) Proposed XMPP Extension: Implicit WebSocket Endpoints -