On Sep 8, 2009, at 3:54 PM, Peter Saint-Andre wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 9/8/09 4:46 PM, Kurt Zeilenga wrote:
On Sep 8, 2009, at 3:14 PM, Peter Saint-Andre wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 9/8/09 3:46 PM, Kurt Zeilenga wrote:
On Sep 8, 2009, at 1:53 PM, Peter Saint-Andre wrote:
The recent discussion about namespaced attributes on the x...@ietf.org
list set me to thinking about the separation of routing
information and
payload data.
Below you use <header/> in your examples, which per XEP-0131 is
for
"non-addressing information about the stanza", which seems to be
payload
data to me.
Sort of. :)
Could you revise your suggestion to discussing moving say
<addresses/>
[XEP-0033] information, which is more obviously routing
information,
into attributes of the stanza?
One can do that in one's own mind.
Well, in my mind, I don't see how to, in a straight-forward way,
map the
examples in section 3 and 4 of XEP 33 into attributes of the stanza.
One would likely end up with an attribute of:
addresses:addresses="base64-of-addresses-element"
Which doesn't seem terribly desirable, so I wonder if you had
something
else in mind.
XEP-0033 is not necessarily terribly desirable. :) Does it truly solve
the problem? Those who have implemented it tell me "not really"...
Likely so. However, I was just using it as an example of "routing
information" in discussing your proposal.
I don't mind adding additional routing attributes to the stanza given
a clear need (which I don't see), but I think it unwise to include
additional meta-information attributes, such as information contained
in <headers/>, in the stanza.
I think attributes of the stanza should be quite limited. So without
a well justified need to add an additional attribute, I rather stick
with the current additional routing approach (ala XEP 33) and meta-
information approach (ala XEP 131) of additional child elements.
Inspection of child elements to find such information doesn't concern
me at all.
-- Kurt
