Re: [Standards] Privacy lists and the order of items

2009-05-11 Thread Remko Tronçon
On Mon, May 11, 2009 at 5:51 PM, Dave Cridland  wrote:
> This did get me wondering about the issue that if there's two semantically
> identical forms for the same information, then should we ever wish to have
> clients sign the privacy list, we have a C14N problem.

Well, semantical equivalence  should be checked at the XML level, not
at the XMPP level. Wouldn't you otherwise have problems with plain
messages as well, since
ab is equivalent to
ba in XMPP (but not
in XML).

cheers,
Remko


Re: [Standards] Privacy lists and the order of items

2009-05-11 Thread Waqas Hussain
On Tue, May 12, 2009 at 4:40 AM, Justin Karneges
 wrote:
> On Monday 11 May 2009 16:28:00 Waqas Hussain wrote:
>> On Mon, May 11, 2009 at 7:10 PM, Peter Saint-Andre 
> wrote:
>> > Can you trust the order of items?
>>
>> Err, explain to me why you wouldn't. Order of nodes (except attributes
>> on an element) is significant in XML.
>
> I've heard that some XMPP codebases out there may (stupidly?) store a stanza's
> element hierarchy in a "hash" tree or other, which may not maintain element
> order.  So the XML is parsed properly, and stanzas are processed in order,
> but elements within a stanza may not be processed in order because the
> ordering is lost during the dom->hash transition.
>
Making life difficult for everyone else because of (stupid?) codebases
which may be out there... Said codebases are not based on any standard
API (DOM, SAX, etc) for one, and wouldn't work correctly for many of
the existing XEPs anyway.

> I want to say at least one such codebase was using Perl, where it's
> commonplace to use these hash trees for everything.  Not that I'm saying it's
> right...
>
So.. since the codebase you are referring to uses hashtables, and
therefore can't handle two children with the same name (or whatever
hash key they are using), XMPP would never allow that to happen?
(Several specs do in fact allow it to happen, some might even require
it.)

And if we are saving codebases, there's XML and UTF-8 and
stringprepping! I'm sure we would save a LOT of codebases out there,
if we dropped the valid XML requirement, etc. Look at HTML 5. They
have added polite handling guidelines for "badly-formed code" to the
specification itself, so we might as well too...

This may appear snarky, but I'm mostly somewhere between bemused and amused.

> -Justin
>

--
Waqas Hussain


Re: [Standards] Privacy lists and the order of items

2009-05-11 Thread Justin Karneges
On Monday 11 May 2009 16:28:00 Waqas Hussain wrote:
> On Mon, May 11, 2009 at 7:10 PM, Peter Saint-Andre  
wrote:
> > Can you trust the order of items?
>
> Err, explain to me why you wouldn't. Order of nodes (except attributes
> on an element) is significant in XML.

I've heard that some XMPP codebases out there may (stupidly?) store a stanza's 
element hierarchy in a "hash" tree or other, which may not maintain element 
order.  So the XML is parsed properly, and stanzas are processed in order, 
but elements within a stanza may not be processed in order because the 
ordering is lost during the dom->hash transition.

I want to say at least one such codebase was using Perl, where it's 
commonplace to use these hash trees for everything.  Not that I'm saying it's 
right...

-Justin


Re: [Standards] Privacy lists and the order of items

2009-05-11 Thread Waqas Hussain
On Mon, May 11, 2009 at 7:10 PM, Peter Saint-Andre  wrote:
> On 5/11/09 1:59 AM, Remko Tronçon wrote:
>>> Also, I'm wondering why the order attribute is used on privacy lists'
>>> items, instead of using the implicit order of the items.
>>
>> I always wondered that myself. I assume it's historical baggage. A
>> pity though, because it makes things needlessly complicated to
>> implement on both client and server side.
>
> Can you trust the order of items?
>
Err, explain to me why you wouldn't. Order of nodes (except attributes
on an element) is significant in XML. An XML vocabulary may not make
use of it, but I don't see why you wouldn't want to in this case. I
don't know of a single XML-traversal API that wouldn't let you iterate
over the items in document-order (indeed, in pretty much all, that's
either the only, or the most convenient traversal method).

If the decision to use the order attribute was only due to lack of
trust of the intrinsic item order, then the answer to (a) in my
original post is yes, and maybe to (b) too. Right?

By the way, if you can't trust the order of your XML, the various XMPP
specs' dependency on in-order processing would be affected. Sending
multiple stanzas in a single TCP/BOSH packet would start having
consequences.

> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
--
Waqas Hussain


Re: [Standards] Privacy lists and the order of items

2009-05-11 Thread Dave Cridland

On Mon May 11 15:10:04 2009, Peter Saint-Andre wrote:

Can you trust the order of items?


This did get me wondering about the issue that if there's two  
semantically identical forms for the same information, then should we  
ever wish to have clients sign the privacy list, we have a C14N  
problem.


I'm not sure that we ever want to, mind, so I'm not sure this is a  
serious concern in the slightest.


Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


Re: [Standards] Privacy lists and the order of items

2009-05-11 Thread Remko Tronçon
> Can you trust the order of items?

If you couldn't, then generated XHTML-IM pages would be quite interesting.

cheers,
Remko


Re: [Standards] Privacy lists and the order of items

2009-05-11 Thread Peter Saint-Andre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 5/11/09 1:59 AM, Remko Tronçon wrote:
>> Also, I'm wondering why the order attribute is used on privacy lists'
>> items, instead of using the implicit order of the items.
> 
> I always wondered that myself. I assume it's historical baggage. A
> pity though, because it makes things needlessly complicated to
> implement on both client and server side.

Can you trust the order of items?

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoIMbwACgkQNL8k5A2w/vyL4wCg+BCWuw0hHNk4iXhhIDvaMXXo
seEAnA5v+J4Wk1JKis/8KL0wvKro8jay
=i5Rn
-END PGP SIGNATURE-


Re: [Standards] Privacy lists and the order of items

2009-05-11 Thread Remko Tronçon
> Also, I'm wondering why the order attribute is used on privacy lists'
> items, instead of using the implicit order of the items.

I always wondered that myself. I assume it's historical baggage. A
pity though, because it makes things needlessly complicated to
implement on both client and server side.

cheers,
Remko


[Standards] Privacy lists and the order of items

2009-05-11 Thread Waqas Hussain
If a client adds/edits a privacy list

a) may a server reorder the list's item elements (sorted by the order
attribute for example)? That is, the client saves

  
  

but on retrieval gets

  
  


b) may a server change the value of the order attributes (making them
consecutive for example)? That is, the client saves

  
  

but on retrieval gets

  
  


In all of the above, the lists are equivalent, but the XML is not.

Also, I'm wondering why the order attribute is used on privacy lists'
items, instead of using the implicit order of the items. Am I missing
something, or is this historical baggage? I don't see anything gained
by explicitly specifying order. Part of some discarded list editing
protocol maybe?

--
Waqas Hussain