[Standards] Response Stream Namespace Qualification

Peter Saint-Andre stpeter at stpeter.im
Tue Feb 14 03:17:59 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/30/12 2:53 PM, Mike Wacker wrote:
> 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?

Yes, that's something to consider for rfc6120bis. I'll add it to my list.

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

It's not clear to me what you intend the behavior of such clients to
be. When you say "expect that some clients would assume...", does that
assumption have behavioral implications (e.g., return an error if the
streams are not qualified consistently)?

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/

iEYEARECAAYFAk850mcACgkQNL8k5A2w/vwFbQCfXStBfPd7BpqSZXrsV2MQSHK9
EWkAnjaOnqWIIjxJzdimB0VIo86Otyul
=c8Hv
-----END PGP SIGNATURE-----



More information about the Standards mailing list