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
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
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 wr
021, 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,
>> XE
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
>
ML 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
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.co
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