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.sm...@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
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
