Re: [Standards] Council Minutes 2021-02-03
> 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? > You not emitting in the correct order is an interop concern as we've seen, > but is broadly something we can argue about. You not caring about ordering > when forwarding seems like it's broken. I emit in the correct order, even if it’s not the original order. I maintain order where it matters. In the case of a data forms with after the s, my implementation would forward the “correct” version with first. Is that worse than sending the original? I feel like there’s something in the spec I am missing here. > On Feb 17, 2021, at 9:44 AM, Dave Cridland wrote: > > > > 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 + > namespace) is stable. Child elements of the same type will always appear > contiguously. > > > OK, this sounds like a bug you may wish to fix. > > There's nothing in our specifications which says that ordering is > insignificant, and general principles such as the end-to-end principle very > strongly suggest you shouldn't be messing with any ordering which could - to > the endpoints - be significant (even if you think it isn't). > > There are practical examples which could be covered by your code here, like > security labelling in PubSub, which (in practise, and contrary to what > XEP-0314 says on the issue) adds child elements to the after the > payload, and consumers assume the first element is always the payload. > > But also XML C14N-based signing (such as XMLDSIG, which also happens in the > real world) would be broken by element reordering. > > You not caring about ordering on parsing is fine. You not emitting in the > correct order is an interop concern as we've seen, but is broadly something > we can argue about. You not caring about ordering when forwarding seems like > it's broken. > > We don’t have a good way to annotate/enforce that certain child element types > need to appear before other child element types. > > 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 unexpected. > > >> On Feb 17, 2021, at 7:27 AM, Dave Cridland wrote: >> >> >> >> >> 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 just encodes unknown XML into a struct that >> maintains child order. It’s just a pain to bake those into the spec. >> >> > Fields in forms are assumed to be ordered as well, >> >> No. The order of XData fields in a form (“x”) is maintained. It’s a list of >> fields. The order that could change is whether the list of instructions >> comes after the list of fields. >> >> https://github.com/processone/xmpp/blob/master/specs/xmpp_codec.spec#L2027-L2028 >> >> But you reorder different elements with anything that has a spec when >> forwarding, is that right? >> >> Dave. >> ___ >> 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 mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ smime.p7s Description: S/MIME cryptographic signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
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 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. This does not include the SASL stuff >> where we cannot have it. >> >> > ___ > 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] 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 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 truly insignificant - those are all OK, though unexpected. >>> >>> >>> Well, kinda ok. Not all namespace prefixing is legal in 6120, and >>> preserving it is a SHOULD. >> >> I am looking forward to draft-crocker-inreply-react so I can +1 this. >> >> >> /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 > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
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 type will always appear contiguously. We don’t have a good way to annotate/enforce that certain child element types need to appear before other child element types. Attribute order, namespacing method (xmlns vs. prefix), and insignificant white space could also change. > On Feb 17, 2021, at 7:27 AM, Dave Cridland wrote: > > > > >> 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 just encodes unknown XML into a struct that >> maintains child order. It’s just a pain to bake those into the spec. >> >> > Fields in forms are assumed to be ordered as well, >> >> No. The order of XData fields in a form (“x”) is maintained. It’s a list of >> fields. The order that could change is whether the list of instructions >> comes after the list of fields. >> >> https://github.com/processone/xmpp/blob/master/specs/xmpp_codec.spec#L2027-L2028 > > But you reorder different elements with anything that has a spec when > forwarding, is that right? > > Dave. > ___ > 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] 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 child order. It’s just a pain to bake those into the spec. > Fields in forms are assumed to be ordered as well, No. The order of XData fields in a form (“x”) is maintained. It’s a list of fields. The order that could change is whether the list of instructions comes after the list of fields. https://github.com/processone/xmpp/blob/master/specs/xmpp_codec.spec#L2027-L2028 > On Feb 16, 2021, at 4:25 AM, Dave Cridland wrote: > > > > 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 structured text using XML > markup. > > Fields in forms are assumed to be ordered as well, I think, so absent > XEP-0141 one could argue that the order isn't important I suppose. > > Dave. > ___ > 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] 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 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 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 = <<" var='field-name-one' label='description' > type='text-single'/> var='field-name-two'>field-value var='field-name-three'>field-value">>. > <<" var='field-name-one' label='description' type='text-single'/"...>> > 3> ReportedLast = <<" var='field-name-two'>field-value var='field-name-three'>field-value var='field-name-one' label='description' > type='text-single'/>">>. > <<" var='field-name-two'>field-value> > 4> xmpp:decode(fxml_stream:parse_element(ReportedFirst)) == > xmpp:decode(fxml_stream:parse_element(ReportedLast)). > true > ``` > > There’s no way for them to detect the invalid order in the server code, > because the CODEC hands them a record/struct. They do write it in the correct > order because their implementation happened to use lists to element refs > instead of maps. > > Our model-based CODEC isn’t public. We happened to use lists for element > references, but also looked at maps/dictionaries. There are tradeoffs, and a > map-based DSL does provide some advantages, including automatic detection of > duplicated keys. While some languages have ordered maps in their standard > libraries, others do not. OCaml doesn’t. > > I am unsure if other folks are using a map-based DSL for a model driven > CODEC. I don’t see the value in starting to enforce the order on these > elements. > > Thanks, > Drew > > > On Feb 10, 2021, at 4: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 field while parsing the following s. > > > > Right, so you're parsing using a SAX-style parser and if comes > > after (or in between) the s, you'd need to use a two-pass parser, is > > that correct? > > > > This is more or less the case I suspected might exist. Most (if not all) > > early XMPP libraries use that kind of approach, whereas a lot of later ones > > pull stanzas out of the XMLStream as documents and then can do XPath-ish > > things on them, so the order matters much less. Smack is, of course, as > > early as they come (along with Strophe and Strophe.js, the former being > > probably forgotten). > > > > So the converse question - are there any libraries which couldn't generate > > XML in order? > > > > Dave. > > ___ > > 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 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] 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 client yet. - Drew > On Feb 14, 2021, at 3:17 PM, Florian Schmaus wrote: > > 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 = <<"> type='result'>> type='text-single'/>> var='field-name-two'>field-value> var='field-name-three'>field-value">>. >> <<"> var='field-name-one' label='description' type='text-single'/"...>> >> 3> ReportedLast = <<"> var='field-name-two'>field-value> var='field-name-three'>field-value> var='field-name-one' label='description' >> type='text-single'/>">>. >> <<"> var='field-name-two'>field-value> >> 4> xmpp:decode(fxml_stream:parse_element(ReportedFirst)) == >> xmpp:decode(fxml_stream:parse_element(ReportedLast)). >> true >> ``` >> There’s no way for them to detect the invalid order in the server code, >> because the CODEC hands them a record/struct. They do write it in the >> correct order because their implementation happened to use lists to element >> refs instead of maps. > > What about the reading side: How does your CODEC assign field types to fields > of incoming data forms? > > - Florian > > > ___ > 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] 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> ReportedLast = <<"field-valuefield-value">>. <<"field-value> 4> xmpp:decode(fxml_stream:parse_element(ReportedFirst)) == xmpp:decode(fxml_stream:parse_element(ReportedLast)). true ``` There’s no way for them to detect the invalid order in the server code, because the CODEC hands them a record/struct. They do write it in the correct order because their implementation happened to use lists to element refs instead of maps. Our model-based CODEC isn’t public. We happened to use lists for element references, but also looked at maps/dictionaries. There are tradeoffs, and a map-based DSL does provide some advantages, including automatic detection of duplicated keys. While some languages have ordered maps in their standard libraries, others do not. OCaml doesn’t. I am unsure if other folks are using a map-based DSL for a model driven CODEC. I don’t see the value in starting to enforce the order on these elements. Thanks, Drew > On Feb 10, 2021, at 4: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 field while parsing the following s. > > Right, so you're parsing using a SAX-style parser and if comes > after (or in between) the s, you'd need to use a two-pass parser, is > that correct? > > This is more or less the case I suspected might exist. Most (if not all) > early XMPP libraries use that kind of approach, whereas a lot of later ones > pull stanzas out of the XMLStream as documents and then can do XPath-ish > things on them, so the order matters much less. Smack is, of course, as early > as they come (along with Strophe and Strophe.js, the former being probably > forgotten). > > So the converse question - are there any libraries which couldn't generate > XML in order? > > Dave. > ___ > 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 ___
