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

[Dave Cridland]

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?
>
>
True, but we know what that override will be, so actually we can handle
that trivially either by including that in the signature or removing it
prior to C14N. I don't have a copy of STANAG 4778 to hand, for example, but
I think that's the approach there.


> > 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?
>
>
OK, then I misunderstood - you always emit the right order? Then I think
that's technically wrong but not in any way I care about.


>  I feel like there’s something in the spec I am missing here.
>

XMPP doesn't say anything at all about reordering as far as I'm aware,
meaning we fall back to XML itself, which treats ordering of child elements
as significant.


>
> > 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
> > 

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

[Florian Schmaus]

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 council session on 2021-02-24 if you
have any.


LGTM

- 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] Council Minutes 2021-02-03

[drew . varner]

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

[Jonas Schäfer]

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):

https://github.com/xsf/xeps/pull/1032/commits/
f0aae567146ab50f2284627966c24684e99ef508

Please provide feedback until the next council session on 2021-02-24 if you 
have any.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Dave Cridland]

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 someone is actually running about putting
xml:space='default' on their stream headers or stanzas.


> Also, it could change
>
>  to 
>
>
Those are the same by definition. (Though interpreted differently in some
parsers, to my annoyance).


> 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
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Sam Whited]

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
___

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

[drew . varner]

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

[Dave Cridland]

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
___

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

[Kevin Smith]

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.

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

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

[Dave Cridland]

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
___

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

[drew . varner]

> 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

[Dave Cridland]

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
___

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

[Jonas Schäfer]

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:







with the relative order of foo vs. bar elements (mind, the order of the bar 
elements to each other mattering is ok!) mattering.

That is because it makes using a data structure like:

{
   ("namespace", "bar"): [element2, element3, element5],
   ("namespace", "foo"): [element1, element4],
}

(syntax: python; {} is a map, () is a tuple, [] is a list)

impossible; you have to extend it with ordering information between the 
differently named elements (e.g. by collecting them under the same key in the 
dictionary, making access to specific elements by type more complicated). I 
think this would impact all but purely streaming implementations heavily, so I 
suggest we avoid this.

Again, the change under discussion is **not** this. But it comes closer to 
that by setting a precedent for the order of *all*  vs. *all*  
("all" instead of "individuals") mattering.

This is why I am reluctant.

With that said: I understand that for streaming processing of forms, it would 
be really neat if we could say that  (being metadata) comes before 
the  elements.

I am **fine** with doing that, but I want it clearly understood (and, maybe 
even consented on) that the other thing outlined above is something we do not 
want [1].

Hence, I hereby change my vote (due to the previous misconception on my side 
regarding the change breaking the implementation I outlined above) to a -0 
instead of a -1.

If we agree this to be a SHOULD instead of a MUST, you can get a +1 from me 
(mainly because it is less staggering for existing implementations).

In any case, a box which mentions this clarification (which it still truly 
isn’t in my mind, but that might be because I don’t think in a streaming 
manner despite using a SAX parser in aioxmpp) would be good to have for people 
coming back at the spec and being confused.

kind regards,
Jonas

   [1]: I am aware that XHTML-IM effectively requires this, however, XHTML-IM
also will generally not be processed by XMPP code but passed onward
as series of SAX events or DOM nodes or even serialised as (X)HTML 
string to downstream code.

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Drew Varner]

> 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

[Dave Cridland]

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
___

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

[Drew Varner]

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

[Dave Cridland]

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 = <<" 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.
>
> 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
___

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

[drew . varner]

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

[Florian Schmaus]

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 = <<"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.


What about the reading side: How does your CODEC assign field types to 
fields of incoming data forms?


- 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] Council Minutes 2021-02-03

[Florian Schmaus]

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 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?


Not SAX but StAX, but not that this is relevant. I guess what is 
relevant is that I cannot rewind the parser (as, for example, a 
DOM-based would allow).


Furthermore, I do not strictly need two XML-parser passes: I could 
collect the information about the fields into a "pseudo-field" data 
structure and assemble the fields with the information found in 
 after I finished parsing the data form. Of course, this 
requires additional code and hence adds complexity.


I honestly did not expect this addition to the XEP to cause so much 
controversy. It appeared clear (to me) that the XEP intention is that 
 comes first, and then the s follow.


I understand that some languages may not come with a linked-map-like 
data structure. However, this appears to be a very commonly used data 
structure. Hence languages like Java and Python ship it as part of their 
runtime libraries. It should also be easy to add such a thing to your 
favorite language (likely it already exists as a library).


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


- 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] Council Minutes 2021-02-03

[Drew Varner]

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
___

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

[Dave Cridland]

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
___

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

[Florian Schmaus]

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 say sender SHOULD order.

4) A combination of both 2 and 3.

The safest for interoperability is probably (4), but I am easy to 
please, I just need some idea of whether any implementations (still) 
exist which rely on the ordering.


I don't care about SHOULD/MUST here, hence I would also be fine with 3).

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.


- 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] Council Minutes 2021-02-03

[Florian Schmaus]

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 claims to be; it
introduces a precedent of requiring relative ordering of unrelated
elements. Dave doesn't think that's actually a new precedent - the existing
text says the 'reported' element describes the data to follow; also
recently noticed that SleekXMPP/SliXMPP already assumes an order. Jonas
isn't sure that imposes a strict ordering requirement, and knows of at
least one implementation which doesn't guarantee the order and would become
non-compliant with such a change. The author, Flow, says that form-field
type-aware parsing of data forms becomes more complex if the order isn't
specified, and it appears to be the norm to have 'reported' first because
people copy directly from the examples. Daniel thought the lack of element
ordering was the reason schemas are non-normative - Flow says that's why
it's specified in the normative text and not the schema. Jonas still isn't
convinced this is a clarification - Flow suggests that any change which
clarifies a normative requirement that wasn't previously explicitly spelled
out could be considered a normative change; sees it as a trade-off. Flow
would tolerate implementations changing the order of first-level stanza
extensions, but not the order of arbitrary elements while en route. Georg
seeks agreement that the updated first commit is indeed a clarification -
Jonas and Zash agree. Dave is happy to discuss this further on the list -
Jonas will reluctantly start a thread.

Jonas: -1
Daniel: [on-list] (too distracted by the bike shed and forgot to read this)
Georg: [on-list]
Dave: [on-list]
Zash: [on-list]


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 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 requirement
means that implementations cannot use hash maps which map the element type
(fully-qualified XML name) to a list of element representing objects anymore,
because that structure does not allow storing the ordering of unrelated
elements.


That reads a little bit like an exaggeration given that LinkedHashMap 
(Java) and OrderedDict (Python) exists.


Hence, I am sorry, but I do not follow that argument.



If you have concrete examples where that is the case, please let me
know.


What is "that" here?

- 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] Council Minutes 2021-02-03

[Ruslan N. Marchenko]

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 while still preserving the order. But I really cannor
> > recall
> > where it was coming from :(
> Maybe this one:
> https://xmpp.org/extensions/xep-0115.html#ver-gen entry 7b and 
> 7cb
> 
That goes about explicit sorting which removes necessity to preserve
order. But 0115 was the reason I implemented forms in the first place
and I've added ordering support later. So should be something
different. Maybe it was just for unit tests though (to have predictable
order).

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

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

[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 while still preserving the order. But I really cannor recall
> where it was coming from :(
Maybe this one: https://xmpp.org/extensions/xep-0115.html#ver-gen entry 7b and 
7cb


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

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

[Ruslan N. Marchenko]

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 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
> requirement 
> means that implementations cannot use hash maps which map the element
> type 
> (fully-qualified XML name) to a list of element representing objects
> anymore, 
> because that structure does not allow storing the ordering of
> unrelated 
> elements. If you have concrete examples where that is the case,
> please let me 
> know.
> 

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 coming from :(

> Introducing this restriction this late into the standards process for
> no 
> interoperability reason and in a Final standard is not justified.
> 
> kind regards,
> Jonas
> ___
> 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

[Dave Cridland]

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
> requirement
> means that implementations cannot use hash maps which map the element type
> (fully-qualified XML name) to a list of element representing objects
> anymore,
> because that structure does not allow storing the ordering of unrelated
> elements. If you have concrete examples where that is the case, please let
> me
> know.
>

As noted, SliXMPP (and SleekXMPP, upon which it is based) both have an
ordering implied. I do not know the code well enough to know if this has an
effect on the acceptable order, or just the emitted output.

https://github.com/fritzy/SleekXMPP/blob/develop/sleekxmpp/plugins/xep_0004/stanza/form.py#L27

After checking the source a little, my guess is that SleekXMPP can consume
the form elements in any order, but always generates them in a fixed order.

This could have been done for aesthetic reasons - bear in mind as
developers serialise XMPP's XML into text in a stylistic manner, so it's
not unexpected we might have chosen to do this purely to make the generated
XML look better.

However, the commit log for adding the OrderedSet to this line includes
this comment:

"Modified stanzabase to use an ordered dict so that can guarentee the that
'items' in a form are added after reported."

This is, in fact, the precise "clarification" made by the PR.

My deduction from this is that such a guarantee was needed; that is, that
there exist some implementations which require a strict ordering which is
certainly implied in the XEP:

"One and only  element, which can be understood as a "table
header" describing the data to follow."

The XML Schema does, of course, specify an ordering; but I accept that's
because *not* specifying an ordering is actually very difficult in XML
Schema from what I recall.

Anyway, what we may have is:

a) There exist, or existed, implementations which relied on an ordering.
b) The XEP implies, but not very explicitly, an ordering.
c) Many existing implementations do not require, or produce, any ordering.

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 say sender SHOULD order.
4) A combination of both 2 and 3.

The safest for interoperability is probably (4), but I am easy to please, I
just need some idea of whether any implementations (still) exist which rely
on the ordering.

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

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

[Jonas Schäfer]

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 requiring relative ordering of unrelated
> elements. Dave doesn't think that's actually a new precedent - the existing
> text says the 'reported' element describes the data to follow; also
> recently noticed that SleekXMPP/SliXMPP already assumes an order. Jonas
> isn't sure that imposes a strict ordering requirement, and knows of at
> least one implementation which doesn't guarantee the order and would become
> non-compliant with such a change. The author, Flow, says that form-field
> type-aware parsing of data forms becomes more complex if the order isn't
> specified, and it appears to be the norm to have 'reported' first because
> people copy directly from the examples. Daniel thought the lack of element
> ordering was the reason schemas are non-normative - Flow says that's why
> it's specified in the normative text and not the schema. Jonas still isn't
> convinced this is a clarification - Flow suggests that any change which
> clarifies a normative requirement that wasn't previously explicitly spelled
> out could be considered a normative change; sees it as a trade-off. Flow
> would tolerate implementations changing the order of first-level stanza
> extensions, but not the order of arbitrary elements while en route. Georg
> seeks agreement that the updated first commit is indeed a clarification -
> Jonas and Zash agree. Dave is happy to discuss this further on the list -
> Jonas will reluctantly start a thread.
> 
> Jonas: -1
> Daniel: [on-list] (too distracted by the bike shed and forgot to read this)
> Georg: [on-list]
> Dave: [on-list]
> Zash: [on-list]

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 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 requirement 
means that implementations cannot use hash maps which map the element type 
(fully-qualified XML name) to a list of element representing objects anymore, 
because that structure does not allow storing the ordering of unrelated 
elements. If you have concrete examples where that is the case, please let me 
know.

Introducing this restriction this late into the standards process for no 
interoperability reason and in a Final standard is not justified.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___