On 23 Feb 2021, at 09:30, Dave Cridland <d...@cridland.net> wrote: > > > > On Mon, 22 Feb 2021 at 19:02, Florian Schmaus <f...@geekplace.eu > <mailto:f...@geekplace.eu>> wrote: > On 2/18/21 12:16 AM, Dave Cridland wrote: > > On Wed, 17 Feb 2021 at 19:22, Kevin Smith <kevin.sm...@isode.com > > <mailto:kevin.sm...@isode.com> > > <mailto:kevin.sm...@isode.com <mailto:kevin.sm...@isode.com>>> wrote: > > > > On 17 Feb 2021, at 18:42, Florian Schmaus <f...@geekplace.eu > > <mailto:f...@geekplace.eu> > > <mailto:f...@geekplace.eu <mailto:f...@geekplace.eu>>> wrote: > > > > > > On 2/16/21 4:14 PM, Jonas Schäfer wrote: > > >> 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 change their code. We need to weigh in the effects of > > the three > > >>> options: > > >>> A: clearly state that the order is not guaranteed > > >>> B: clearly state that the order is guaranteed > > >>> C: state that it should be sent in order, but recipients > > must be able > > >>> to process in any order > > >> You are right. You were also right about what you said in reply > > to my other > > >> email about OrderedMap existing in Python (even being the > > default since some > > >> versions). > > >> However, here is a specific thing I do not want to see in XMPP: > > >> <foo/> > > >> <bar/> > > >> <bar/> > > >> <foo/> > > >> <bar/> > > >> with the relative order of foo vs. bar elements (mind, the order > > of the bar > > >> elements to each other mattering is ok!) mattering. > > > > > > > > > I am with you here, with one additional constraint: I think it is > > relevant where those elements are placed in the stanza. > > > > > > Element ordering is something that is often overlooked in XMPP > > land. My stance is that the order of extension elements *which are > > direct children of a stanza* should be irrelevant (and probably can > > be unstable, e.g., because it was modified by a hop). However, > > extension elements are free to impose order constraints of their > > sub-elements. As it was previously pointed out, we already have such > > elements. > > > > > > I wonder if we have consensus for > > > > > > """ > > > The XML element order is irrelevant for elements that a direct > > children of a stanza, and for all other elements unless explicitly > > specified. > > > “"" > > > > I think the reverse of part two is true, actually. > > > > I think the order of stanza children isn’t relevant (extensions can > > be put in any order), > > At least we agree on something. :) > > > but within an extension the order should be > > maintained unless otherwise explicitly stated. > > > > /K > > I think, broadly, that stanza contents can be re-serialized in any way > > that would not alter the canonicalized form, and not otherwise. > > > > So if you want to reorder attributes, go for it. Reorder elements, not > > so much. > > > > There are some obvious exceptions: > > > > Servers can insert new elements just fine and - in rare cases - remove > > them too, but that's really because those extensions are specifically > > designed for it, like <delay/> or security labelling. > > > > Otherwise, I don't really understand why anyone would think reordering > > things inside a stanza would be a good idea by default. The fact it > > doesn't usually cause a problem is neither an indicator that it cannot, > > nor an indicator that it should, and given XML has *always* had order as > > a significant thing, I don't understand why "we've never explicitly said > > you can't" should be taken as an indicator that therefore you can. > > > > So broadly, Florian, not consensus from me. > > I had my fancy XMPP client developer goggles on when I wrote this. It > occurred to me that you and Kev are talking about maintaining the order > when re-serializing XML. Which takes the perspective of a sever routing > stanzas. > > > Ah! Yes, serialization order should remain stable in routing. > > But does it really matter in which order a client emits <body/> and > other first-level, i.e. directly below the stanza element, extension > elements? I do not think so, and I believe we should forbid any semantic > of the ordering of first-level stanza extension elements. > > > But ordering of stanza immediate child elements by the client (and additions > by servers, actually) can be in any order. > > And the ordering within most extension elements is also irrelevant. Take > <forwarded/> for example: It doesn't matter if the <delay/> comes before > the forwarded <message/> or not. Hence XEP-0297 does not contain a > single sentence with order requirements. → The order is implicitly > irrelevant. However, certain extension elements require a particular > ordering: Like the <reported/> from xep4 that triggered this discussion. > Here we will (probably) explicitly specify the order requirement. > > > I think this is broadly correct, but I think this one is laced through with > "typically" and "mostly", so if you're not sure, order. > > There is a sort of weird archeology in all this: > > * XML itself assumes ordering of elements is significant. > * XML Schemas provide no way to indicate that ordering is not significant, as > far as I've ever found. > * Most XMPP extensions then remove this ordering requirement, but only > implicitly. > * So now we seem to lean toward needing explicit ordering requirements to > undo the implicit non-ordering requirements we implicitly place on the > explicit base layer of XML. > > I mean, if I were going to get excitable about exactly what's written in our > specifications, I don't think we ever explicitly say that the ordering of > child elements in <forwarded/> is not significant, do we? The only thing that > mentions anything about ordering is the schema, which say that <delay/> > always comes first if present. > > Obviously this isn't the case in practice, but this is the pitfall we end up > in. > > > This could mean for a stanza routing entity that it is free to re-order > first-level extension elements and within all elements where it knows > that the order is irrelevant. If server developers see a benefit in this > kind of freedom, then I do not see a reason why we should not allow it. > > No, I'd not go that far. > > While an extension might not have any semantic meaning to ordering, other > things built on the result can and do rely on the ordering being at least > stable. Anything involving C14N is the obvious case, but some things relating > to XPath as well. As an example, if we used XMLDSIG over that <forwarded/> > element, that seems to add significance to the element ordering once again. > > Moreover, I do worry about the practicality of saying that when routing > stanzas, servers can parse the thing entirely into an internal representation > and then reserialize - I worry about risks of losing elements and attributes > (and attribute values and so on) that it doesn't understand. I've seen all > sorts of crazy over the years, but for an easy example we might all remember, > Buddycloud added an additional affiliation value to Pubsub. We might (and > probably should) moan about extending without proper namespaces etc, but > people do this and I think reasonably expect it to work. We do not, as a > rule, encourage schema validation within the network.
I think I broadly agree with this (other than that the anecdote of adding un-namespaced extensions to standard protocol is a thing that is evil and bad, and people should not expect this to work outside a closed system). Clients should know whether element ordering is significant for everything they send or consume. Servers can’t know this in the general case, and so shouldn’t change it while forwarding. /K
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
