[Standards-JIG] Re: blocking namespace
machekku at uaznia.net
Tue Nov 21 22:46:17 UTC 2006
Peter Saint-Andre wrote:
> Maciek Niedzielski wrote:
>> Peter Saint-Andre wrote:
>>> I have been told by an IETF area director that when we start using the
>>> urn:xmpp: NID is up to us. I would like to start using them as soon as
>>> possible because the old-style HTTP URIs are problematic for all the
>>> reasons explained in draft-saintandre-xmpp-urn. Therefore I propose that
>>> we make XEP-0191 the guinea pig and specify the following namespaces for
>>> use in simple communications blocking:
>> If this XEP is going to end up as a new RFC chapter, we'll probably have
>> to change it to urn:ietf:something anyway ;)
> It won't, because rfc3921bis simply refers to it and I don't see that
Oh, I'd think that if blocking is mandatory for IM protocol (at least to
make it RFC), then it must be defined in the RFC itself, not just
referencing. I always thought that this is why some XEPs were
incorporated into the first RFC.
Using a link to other spec (a no-RFC spec) is a bit tricky, because XEPs
are much easier to change. RFC cannot really be changed (new version
gets new number). If we link to a XEP, then the XMPP definition (with
its mandatory blocking) becomes a bit fuzzy. What if the XEP changes
after publishing the RFC? Should the implementor use the latest XEP
version? Or the last version before RFC was published? If all mandatory
features are defined in the RFC, it is possible to say what XMPP is. But
if we link to a changeable XEP, you can change XMPP without publishing
new version of the RFC.
Maciek A: It's against natural order of reading.
xmpp:machekku at uaznia.net Q: Why is that?
xmpp:machekku at chrome.pl A: People answering above quoted text.
Q: What's the most annoying on newsgroups?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 257 bytes
Desc: OpenPGP digital signature
More information about the Standards