[Standards] Call for Experience: Advancement of XEP-0047 (In-Band Bytestreams) to Final

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

At its meeting on December 20, 2011, the XMPP Council agreed to issue
a "Call for Experience" regarding XEP-0047 (In-Band Bytestreams), in
preparation for perhaps advancing this specification from Draft to
Final in the XSF's standards process. To help the Council decide
whether this XEP is ready to advance to a status of Final, the Council
would like to gather the following information:

1. What software has implemented XEP-0047? Please note that the
protocol must be implemented in at least two separate codebases (and
preferably more).

2. Have developers experienced any problems with the protocol as defined
in XEP-0047? If so, please describe the problems and, if possible,
suggested solutions.

3. Is the text of XEP-0047 clear and unambiguous? Are more examples
needed? Is the conformance language (MAY/SHOULD/MUST) appropriate?
Have developers found the text confusing at all? Please describe any
suggestions you have for improving the text.

If you have any comments about advancing XEP-0047 from Draft to Final,
please provide them by the close of business on Friday, February 24,
2012. After the Call for Experience, this XEP might undergo revisions
to address feedback received, after which it will be presented to the
XMPP Council for voting to a status of Final.

You can review the specification here:

http://www.xmpp.org/extensions/xep-0047.html

Please send all feedback to the standards@xmpp.org discussion list.

Thanks!

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/

iEYEARECAAYFAk8nH7UACgkQNL8k5A2w/vzSQwCffoBBmDnr+jJ3aOqrS6LF89AN
WpwAnA+1oPOYJ79N1NkK+1cd9dNu1HhL
=ld4P
-END PGP SIGNATURE-

[Standards] Response Stream Namespace Qualification

[Mike Wacker]

I saw this excerpt in RFC 6120, 4.8.2: An entity MAY declare a "content 
namespace" as the default namespace for data sent over the stream (i.e., 
data other than elements qualified by the stream namespace). If so, (1) 
the content namespace MUST be other than the stream namespace, and (2) 
the content namespace MUST be the same for the initial stream and the 
response stream so that both streams are qualified consistently. The 
content namespace applies to all first-level child elements sent over 
the stream unless explicitly qualified by another namespace (i.e., the 
content namespace is the default namespace).


Reading that section, it suggests that the initial and response stream 
should always be qualified consistently, not just if the initiating 
entity declares a content namespace (e.g.: if the initial stream uses 
the stream namespace as the default namespace, then so should the 
response stream). However, this section on content namespaces is the 
only time the RFC mentions anything about qualifying the two streams 
consistently. If they are supposed to be qualified consistently, SHOULD 
or MUST they be qualified consistently?


More importantly, would it be reasonable to expect that some clients 
would assume the initial and response streams are qualified in the same 
way instead of checking the stream header of the response stream to see 
how the response stream is qualified (in case it's qualified differently 
than the initial stream)?