[Standards] RFC 6120 vs. XEP

Peter Saint-Andre stpeter at stpeter.im
Mon Feb 6 23:46:58 UTC 2017


RFC 6120 author here. :-)

In a message not quoted below, Kev said "Nothing stops further specs 
from changing the core rules by negotiation. This is not a violation, 
it’s agreeing to do something different."

I tend to agree that the main point of stream feature negotiation is to 
make it possible to improve how we start up a session by adding new and 
better features over time. That's the whole idea of discovery (and 
stream features are a kind of discovery before you can use disco).

Note that the order of features matters. In the Bind2 proposal, the 
order is this:

<stream:features>
   <bind xmlns='urn:xmpp:bind2:0'/>
   <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
   <sm xmlns='urn:xmpp:sm:3'/>
</stream:features>

Thus, if a client and server both support Bind2, the client could use 
Bind2 instead of 6120 binding.

In RFC 6120, "mandatory-to-negotiate" does not mean that we can never 
replace such a feature, it means that the initiating entity must use the 
feature if it hasn't already negotiated something equivalent with the 
receiving entity. In this case, the client would use Bind2 and the 
server would not offer 6120 binding afterward.

Therefore I see nothing in Bind2 that is technically problematic in this 
respect.

Further process comments below.

On 2/6/17 1:37 PM, Marvin Gülker wrote:
> On Mon, Feb 06, 2017 at 06:09:50PM +0300, Evgeny Khramtsov wrote:
>> Mon, 6 Feb 2017 14:57:10 +0000
>> Kevin Smith <kevin.smith at isode.com> wrote:
>>
>>> Not really, that’s just how extensions work.
>>
>> I disagree. Extensions should extend, not replace, the RFC. Replacing
>> RFCs by XEPs is some new phenomenon introduced in recent years.
>
> Yes. An extension is something building on top of the RFC, not
> contradicting it.

This is not really a contradiction, it is an intended improvement 
(without using the same namespace - *that* would be a contradiction) and 
eventual replacement.

The word "eventual" is important here.

> What is not spelled out here, but I guess what is behind Kevin's
> position, is that amending RFC 6120 would be a time-consuming process as
> it needs to go through the IETF.

Having authored both RFC 3920 and RFC 6120, I know better than anyone 
else here that updating or replacing RFCs is indeed time consuming. :) 
However, I don't think that's the main issue here. Indeed, we have 
always planned to publish an RFC that replaces 6120 and includes some 
fixes we know are needed (most of them relatively small). This Bind2 
work would merely add to the list of changes.

> In the current changing world of mobile
> messaging, a time-consuming standardisation process is the last the XMPP
> universe needs.
>
> I can see this point, but in my opinion the approach taken currently is
> the wrong answer to this. RFC 6120 has the advantage that it covers and
> consolidates quite a lot of functionality (together with RFC 6121) at a
> central point. What happens currently is that parts of the RFC are
> superseded by some XEP here, another XEP there, etc. The result is an
> organisational mess.

In the past the XSF has worked on proposals to update or improve core 
features of the streaming protocols - see for example XEPs 29, 32, 34 
and 35. This enabled the community to experiment with improvements and 
then port them over to the RFC when we obtained some implementation and 
deployment experience.

> If replacing RFC 6120f. is what is wanted anyway,
> then why not make some kind of "super-XEP" that consolidates the entire
> thing into one document people can be pointed to, and have that document
> explicitely state "this XEP obsoletes and supersedes RFC 6120 for any
> modern use of XMPP; implementation of RFC 6120 is
> discouraged".

It's not the place of the XSF to obsolete RFCs, because since 2002 we 
have worked closely with the IETF to standardize core work there.

> Preferably, the IETF should be asked to retire the RFC
> 6120 group. This sets things straight again and kicks the IETF out of
> the standardisation boat, where it appearently causes more problems than
> it helps.

Our work with the IETF has been very beneficial, especially with regard 
to security because we have received input from security experts. That's 
not to say it is always easy, but it has led to stronger security (up to 
and including RFC 7590 / RFC 7525).

> If this sounds too radical, why not just submit the changes of the XEPs
> in question to the IETF and have a note in the XEPs that they defer to
> the resulting RFC once it has been approved by the IETF? After all, RFC
> 6120 has aged a little since it was published in 2011.

Although in practice it's not quite that simple, in theory what I would 
propose is similar: let's define Bind2 to the best of our abilities in 
the XSF and gain some implementation and deployment experience with it, 
which we can do in a way that does not contradict RFC 6120 (see above) 
by using a separate namespace. In parallel, let's also figure out what 
other improvements are needed to RFC 6120 and RFC 6121 (to date I think 
the proposed fixes have been relatively minor - Bind2 would be the 
largest of the changes). Then, we start the process of formally updating 
the core RFCs. This will probably involve starting a short-lived working 
group (WG) at the IETF - again, not a matter of "just submitting the 
changes to the IETF", but a well-known process for some folks in the 
XMPP community. At that point, the WG is not "those strange IETF people 
who we don't know around here", but *us* because we'll be the active 
participants in the WG (which was the case when we worked on RFC 3920 
and RFC 6120).

tl;dr Let's do the best we can on Bind2 and then cross the IETF bridge 
when we come to it.

Peter



More information about the Standards mailing list