Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 5 August 2014 19:11, Ivan Vucica wrote: > On Tuesday, August 05, 2014 03:21:11 PM XMPP Extensions Editor wrote: > > Additionally, the protocol is used to negotitate whether the receiving > > Is the 'negotitate' intentional? > I think it's probably intentitonal...
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On Tuesday, August 05, 2014 03:21:11 PM XMPP Extensions Editor wrote: > Additionally, the protocol is used to negotitate whether the receiving Is the 'negotitate' intentional?
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 8/27/13 2:41 PM, XMPP Extensions Editor wrote: > Version 0.15 of XEP-0220 (Server Dialback) has been released. > > Abstract: This specification defines the Server Dialback protocol, > which is used between XMPP servers to provide identity verification. > Server Dialback uses the Domain Name System (DNS) as the basis for > verifying identity; the basic approach is that when a receiving > server accepts a server-to-server connection from an initiating > server, it does not process XMPP stanzas over the connection until it > has verified the initiating server's identity. Additionally, the > protocol is used to negotitate whether the receiving server is > accepting stanzas for the target domain. Although Server Dialback > does not provide strong authentication and is subject to DNS > poisoning attacks, it has effectively prevented most address spoofing > on the XMPP network since its development in the year 2000. > > Changelog: Addressed Last Call feedback and made editorial > improvements. (psa/ph) Philipp and I have addressed the Last Call feedback and have also completed independent reviews of the spec, leading to clarifications and improvements throughout. In our opinion it's now ready for advancement to Draft, but naturally that decision is a matter for the XMPP Council. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 8/8/12 12:28 PM, Philipp Hancke wrote: > Am 08.08.2012 20:27, schrieb XMPP Extensions Editor: >> Version 0.13 of XEP-0220 (Server Dialback) has been released. > > Now that is finally a version I am (mostly) happy with. Thanks Peter! Huzzah! Wider feedback would be appreciated so we can push this to Draft before long. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
Am 08.08.2012 20:27, schrieb XMPP Extensions Editor: Version 0.13 of XEP-0220 (Server Dialback) has been released. Now that is finally a version I am (mostly) happy with. Thanks Peter!
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 9/19/11 11:03 AM, Peter Saint-Andre wrote: > On 7/7/11 11:37 AM, Peter Saint-Andre wrote: >> On 7/7/11 2:51 AM, Kevin Smith wrote: >>> On Wed, Jul 6, 2011 at 5:59 PM, Peter Saint-Andre >>> wrote: On 5/17/11 2:26 PM, Kevin Smith wrote: > On Tue, May 17, 2011 at 9:20 PM, Peter Saint-Andre > wrote: 1. Child elements as in 0.9: >>> >>> I'm not opposed to this, I think. It has the advantage of not breaking >>> the existing implementations. >> >> The concern is, what happens when someone adds new sub-features in the >> future? > > Hopefully we wouldn't spec new features without versioning and start > seeing interoperable implementations prior to realising in the future > :) > > 3. More features: >>> >>> This one breaks existing dialback error implementations, but not >>> general dialback implementations. This one doesn't seem particularly >>> harmful, compared to (2), and I'll go along with the majority if it's >>> what's deemed sensible. >> >> #3 is more consistent with what we do in service discovery. IMHO that's >> a good thing. > > Yes, #3 is what we have previously agreed is the Right Thing to do > with features. In this case we didn't, and implementations sprouted up > and were deployed before we noticed, so it's a question now of whether > the pragmatic thing is to use what we have, or to break > implementations and maintain spec-hygiene. Kev, I've thought about this some more and I think it's OK to retain this: That's what we've had since version 0.5 of the spec, published on 2010-03-18. I don't like it and I think we need to add a note that this is not the recommended way of defining stream features so that other specs won't emulate this approach, but the protocol hygiene is just not important enough to me here. >>> >>> I'm happy with notes saying that this is the Wrong Thing to do, and we >>> can even give a footnote of what the Right Way is, if we want. >> >> I'll work up some text along those lines for review on the list. > > My apologies for the delay. I propose that we add the following > paragraph at the end of Section 5.2: > >As a general rule, stream feature elements containing child elements >that advertise particular sub-features are not encouraged. The >format shown above is used for the sake of backward compatiblity >with existing implementations and deployments. Sorry, I think that belongs in Section 2.4.2. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 7/7/11 11:37 AM, Peter Saint-Andre wrote: > On 7/7/11 2:51 AM, Kevin Smith wrote: >> On Wed, Jul 6, 2011 at 5:59 PM, Peter Saint-Andre wrote: >>> On 5/17/11 2:26 PM, Kevin Smith wrote: On Tue, May 17, 2011 at 9:20 PM, Peter Saint-Andre wrote: >>> 1. Child elements as in 0.9: >>> >>> >>> >>> >>> >>> >> >> I'm not opposed to this, I think. It has the advantage of not breaking >> the existing implementations. > > The concern is, what happens when someone adds new sub-features in the > future? Hopefully we wouldn't spec new features without versioning and start seeing interoperable implementations prior to realising in the future :) >>> 3. More features: >>> >>> >>> >>> >> >> This one breaks existing dialback error implementations, but not >> general dialback implementations. This one doesn't seem particularly >> harmful, compared to (2), and I'll go along with the majority if it's >> what's deemed sensible. > > #3 is more consistent with what we do in service discovery. IMHO that's > a good thing. Yes, #3 is what we have previously agreed is the Right Thing to do with features. In this case we didn't, and implementations sprouted up and were deployed before we noticed, so it's a question now of whether the pragmatic thing is to use what we have, or to break implementations and maintain spec-hygiene. >>> >>> Kev, I've thought about this some more and I think it's OK to retain this: >>> >>> >>> >>> >>> >>> >>> >>> That's what we've had since version 0.5 of the spec, published on >>> 2010-03-18. I don't like it and I think we need to add a note that this >>> is not the recommended way of defining stream features so that other >>> specs won't emulate this approach, but the protocol hygiene is just not >>> important enough to me here. >> >> I'm happy with notes saying that this is the Wrong Thing to do, and we >> can even give a footnote of what the Right Way is, if we want. > > I'll work up some text along those lines for review on the list. My apologies for the delay. I propose that we add the following paragraph at the end of Section 5.2: As a general rule, stream feature elements containing child elements that advertise particular sub-features are not encouraged. The format shown above is used for the sake of backward compatiblity with existing implementations and deployments. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 7/7/11 2:51 AM, Kevin Smith wrote: > On Wed, Jul 6, 2011 at 5:59 PM, Peter Saint-Andre wrote: >> On 5/17/11 2:26 PM, Kevin Smith wrote: >>> On Tue, May 17, 2011 at 9:20 PM, Peter Saint-Andre >>> wrote: >> 1. Child elements as in 0.9: >> >> >> >> >> >> > > I'm not opposed to this, I think. It has the advantage of not breaking > the existing implementations. The concern is, what happens when someone adds new sub-features in the future? >>> >>> Hopefully we wouldn't spec new features without versioning and start >>> seeing interoperable implementations prior to realising in the future >>> :) >>> >>> >> 3. More features: >> >> >> >> > > This one breaks existing dialback error implementations, but not > general dialback implementations. This one doesn't seem particularly > harmful, compared to (2), and I'll go along with the majority if it's > what's deemed sensible. #3 is more consistent with what we do in service discovery. IMHO that's a good thing. >>> >>> Yes, #3 is what we have previously agreed is the Right Thing to do >>> with features. In this case we didn't, and implementations sprouted up >>> and were deployed before we noticed, so it's a question now of whether >>> the pragmatic thing is to use what we have, or to break >>> implementations and maintain spec-hygiene. >> >> Kev, I've thought about this some more and I think it's OK to retain this: >> >> >> >> >> >> >> >> That's what we've had since version 0.5 of the spec, published on >> 2010-03-18. I don't like it and I think we need to add a note that this >> is not the recommended way of defining stream features so that other >> specs won't emulate this approach, but the protocol hygiene is just not >> important enough to me here. > > I'm happy with notes saying that this is the Wrong Thing to do, and we > can even give a footnote of what the Right Way is, if we want. I'll work up some text along those lines for review on the list. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On Wed, Jul 6, 2011 at 5:59 PM, Peter Saint-Andre wrote: > On 5/17/11 2:26 PM, Kevin Smith wrote: >> On Tue, May 17, 2011 at 9:20 PM, Peter Saint-Andre >> wrote: > 1. Child elements as in 0.9: > > > > > > I'm not opposed to this, I think. It has the advantage of not breaking the existing implementations. >>> >>> The concern is, what happens when someone adds new sub-features in the >>> future? >> >> Hopefully we wouldn't spec new features without versioning and start >> seeing interoperable implementations prior to realising in the future >> :) >> >> > 3. More features: > > > > This one breaks existing dialback error implementations, but not general dialback implementations. This one doesn't seem particularly harmful, compared to (2), and I'll go along with the majority if it's what's deemed sensible. >>> >>> #3 is more consistent with what we do in service discovery. IMHO that's >>> a good thing. >> >> Yes, #3 is what we have previously agreed is the Right Thing to do >> with features. In this case we didn't, and implementations sprouted up >> and were deployed before we noticed, so it's a question now of whether >> the pragmatic thing is to use what we have, or to break >> implementations and maintain spec-hygiene. > > Kev, I've thought about this some more and I think it's OK to retain this: > > > > > > > > That's what we've had since version 0.5 of the spec, published on > 2010-03-18. I don't like it and I think we need to add a note that this > is not the recommended way of defining stream features so that other > specs won't emulate this approach, but the protocol hygiene is just not > important enough to me here. I'm happy with notes saying that this is the Wrong Thing to do, and we can even give a footnote of what the Right Way is, if we want. /K
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 7/6/11 2:14 PM, Philipp Hancke wrote: > Am 06.07.2011 19:30, schrieb XMPP Extensions Editor: >> Version 0.11 of XEP-0220 (Server Dialback) has been released. >> >> Abstract: This specification defines the Server Dialback protocol, >> which is used between XMPP servers to provide identity verification. >> Server Dialback uses the Domain Name System (DNS) as the basis for >> verifying identity; the basic approach is that when a receiving server >> accepts a server-to-server connection from an originating server, it >> does not process traffic over the connection until it has verified a >> key with an authoritative server for the domain asserted by the >> originating server. Although Server Dialback does not provide strong >> authentication or trusted federation and although it is subject to DNS >> poisoning attacks, it has effectively prevented most instances of >> address spoofing on the XMPP network since its development in the year >> 2000. >> >> Changelog: Per list discussion, reverted the stream features >> versioning that was added to version 0.10, thus reverting to the >> format used in versions 0.5 through 0.9 of the spec; corrected several >> errors in the examples. (psa) >> >> Diff: http://xmpp.org/extensions/diff/api/xep/0220/diff/0.10/vs/0.11 >> >> URL: http://xmpp.org/extensions/xep-0220.html >> > > Merely a bug report, more later next week: > http://xmpp.org/extensions/xep-0220.html#advertisement-errors > The text from 0.9 is needed here. Patch attached. ACK! Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
Am 06.07.2011 19:30, schrieb XMPP Extensions Editor: Version 0.11 of XEP-0220 (Server Dialback) has been released. Abstract: This specification defines the Server Dialback protocol, which is used between XMPP servers to provide identity verification. Server Dialback uses the Domain Name System (DNS) as the basis for verifying identity; the basic approach is that when a receiving server accepts a server-to-server connection from an originating server, it does not process traffic over the connection until it has verified a key with an authoritative server for the domain asserted by the originating server. Although Server Dialback does not provide strong authentication or trusted federation and although it is subject to DNS poisoning attacks, it has effectively prevented most instances of address spoofing on the XMPP network since its development in the year 2000. Changelog: Per list discussion, reverted the stream features versioning that was added to version 0.10, thus reverting to the format used in versions 0.5 through 0.9 of the spec; corrected several errors in the examples. (psa) Diff: http://xmpp.org/extensions/diff/api/xep/0220/diff/0.10/vs/0.11 URL: http://xmpp.org/extensions/xep-0220.html Merely a bug report, more later next week: http://xmpp.org/extensions/xep-0220.html#advertisement-errors The text from 0.9 is needed here. Patch attached. diff --git a/extensions/xep-0220.xml b/extensions/xep-0220.xml index c0a4aa2..1272053 100644 --- a/extensions/xep-0220.xml +++ b/extensions/xep-0220.xml @@ -442,7 +442,7 @@ send: - If a server supports graceful handling of dialback errors as described under Section 2.5, it MUST advertise that though a stream feature which is aelement qualified by the 'urn:xmpp:features:dialback' namespace. + If a server supports graceful handling of dialback errors as described under Section 2.4, it MUST advertise that via a stream feature which is a element qualified by the 'urn:xmpp:features:dialback' namespace, including an empty element.
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 6/30/11 1:28 PM, Philipp Hancke wrote: > Am 18.05.2011 18:19, schrieb Peter Saint-Andre: >> On 5/18/11 12:58 AM, Philipp Hancke wrote: Version 0.10 of XEP-0220 (Server Dialback) has been released. >>> >>> For the record: >>> I disapprove this version because it still contains "serious bugs" >>> (example 7) >> >> You are right that example 7 has a copy and paste error... > > So serious bugs degrade to "copy and paste error" when you no longer > need them to support your argument for a rewrite? Interesting. It was a copy-and-paste error. It happens to have been a somewhat serious copy-and-paste error, but that's what it was. You can spin it however you like, but I must say that I really don't appreciate your snarky tone. > You have also introduced yet another copy and paste mistake in the most > recent version: > > Example 18. Stream Features With Element > > does not show the any more and additionally > > > > > is not valid xml. Fixed in 0.11. > And sorry for using this bad word again, but isn't it ridiculous to > publish a new version with a debatable change and then not to do > anything for weeks? Working 80 hours a week will do that to a person. I'm sure you understand. > What would have happened if anyone actually implemented this would-be > way of advertising support for dialback errors? It's an experimental spec. Anyone following the list would know that it's provisional, especially given all the discussion on this particular point in the text. Anyone not following the list is not being very smart about how they implement XMPP. > Are you waiting for someone to implement your version so you can claim > "running code"? See above regarding snarkiness. You might want to familiarize yourself with Hanlon's Razor. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 5/18/11 12:58 AM, Philipp Hancke wrote: >> Version 0.10 of XEP-0220 (Server Dialback) has been released. > > For the record: > I disapprove this version because it still contains "serious bugs" > (example 7) and is published without my approval as an author. It was published without Jeremie's approval as a co-author, too. :P Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 5/17/11 2:26 PM, Kevin Smith wrote: > On Tue, May 17, 2011 at 9:20 PM, Peter Saint-Andre wrote: 1. Child elements as in 0.9: >>> >>> I'm not opposed to this, I think. It has the advantage of not breaking >>> the existing implementations. >> >> The concern is, what happens when someone adds new sub-features in the >> future? > > Hopefully we wouldn't spec new features without versioning and start > seeing interoperable implementations prior to realising in the future > :) > > 3. More features: >>> >>> This one breaks existing dialback error implementations, but not >>> general dialback implementations. This one doesn't seem particularly >>> harmful, compared to (2), and I'll go along with the majority if it's >>> what's deemed sensible. >> >> #3 is more consistent with what we do in service discovery. IMHO that's >> a good thing. > > Yes, #3 is what we have previously agreed is the Right Thing to do > with features. In this case we didn't, and implementations sprouted up > and were deployed before we noticed, so it's a question now of whether > the pragmatic thing is to use what we have, or to break > implementations and maintain spec-hygiene. Kev, I've thought about this some more and I think it's OK to retain this: That's what we've had since version 0.5 of the spec, published on 2010-03-18. I don't like it and I think we need to add a note that this is not the recommended way of defining stream features so that other specs won't emulate this approach, but the protocol hygiene is just not important enough to me here. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
Am 18.05.2011 18:19, schrieb Peter Saint-Andre: On 5/18/11 12:58 AM, Philipp Hancke wrote: Version 0.10 of XEP-0220 (Server Dialback) has been released. For the record: I disapprove this version because it still contains "serious bugs" (example 7) You are right that example 7 has a copy and paste error... So serious bugs degrade to "copy and paste error" when you no longer need them to support your argument for a rewrite? Interesting. You have also introduced yet another copy and paste mistake in the most recent version: Example 18. Stream Features With Element does not show the any more and additionally is not valid xml. And sorry for using this bad word again, but isn't it ridiculous to publish a new version with a debatable change and then not to do anything for weeks? What would have happened if anyone actually implemented this would-be way of advertising support for dialback errors? Are you waiting for someone to implement your version so you can claim "running code"?
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
Peter Saint-Andre wrote:
[...]
However, if you think it is ridiculous to choose option #1 (despite the
fact that this is what RFC 3920 did), then we can continue to discuss
the topic on this list, you can appeal to the XMPP Council,
I had evaluated option #1 when writing the initial 0.4. It is much less
useful when debugging because typically dialback happens twice during a
bidirectional session and with this option it is harder to figure out
which packet belongs to which session.
Option #1 is what we had in RFC 3920. That doesn't seem to have
prevented implementation and deployment of server dialback.
Most implementations I know predate RFC 3920.
Who implemented dialback based on 3920 (or any of the draft versions)?
Who implemented dialback from 0220?
Who implemented dialback by playing with jabberd?
(I have to admit that the figure in rfc 3920 8.2 was really helpful)
I would not advise people who can not deal with the confusion perceived
by you in the (corrected) version 0.8 to attempt implementing dialback,
because what happens on the wire is even more complicated.
At one time I worked on extremely detailed server-to-server examples in
XEP-0238 (XMPP Protocol Flows for Inter-Domain Federation) but it was a
lot of work to maintain.
0238 is really great at showing why we need to get rid of EXTERNAL (-:
So I do not see why now, after 18 months, this change is necessary nor
why it has to be done over the weekend.
Because mixing the directions in the middle of the examples is extremely
confusing.
The direction changes between sub-subsections, not in the middle of the
examples. The initial 0.4 was quite explicit about the who-is-who in the
header, for 2.1 it had something along the lines of:
(still using the old 0.3 hostnames)
> This subsection describes the interaction between the Originating
> Server ('example.org') and the Receiving Server ('xmpp.example.com'),
> from the perspective of the Originating Server.
That way, the 'send' operation/direction was always using
from=example.org in section 2.1 whereas the recv was always associated
with to=example.org in 2.2.
Your way switches send/recv, e.g. in 2.1.1 and 2.2.1 sender.tld is
sending, in 2.1.2 and 2.2.2 target.tld is sending. That is less confusing?
(obviously, the suggestive hostnames are not helpful)
Now, I'd be fine with adding another *complete* set of examples showing
the negotiation in direction 2, resulting in sections like this:
I think we can get a shorter version of this by adding another figure in
section 1.3 which shows the second direction and say where the examples
plug in.
2. "Protocol Flow for Negotiating Connection From sender.tld to target.tld"
(i.e., the current Sections 2.1 and 2.2)
>
3. "Directionality"
(i.e., the current Section 2.3)
(which is currently not very explicit regarding the use of a different
tcp connection for this)
4. "Protocol Flow for Negotiating Connection From target.tld to sender.tld"
(new section similar to 2.1 and 2.2 but in the other direction, so we
don't leave direction 2 as an exercise for the reader as in RFC 3920)
Some implementations will start to negotiate this before the other
dialback process is finished. So a simplified "first this direction,
then the other direction" description is not helpful
(see e.g.
http://mail.jabber.org/pipermail/standards/2010-April/023420.html ).
If you want to document all variants then you will end up with something
that is even longer than 0238. If you go down that path you will end up
describing a session with two hostnames on each side and source/target
piggybacking. *shudder*
However, I continue to think that mixing direction 1 and direction 2 in
the current Sections 2.1 and 2.2 is way too confusing.
See above.
philipp
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On Tue, May 17, 2011 at 02:20:58PM -0600, Peter Saint-Andre wrote: > Bad copy and paste, should be: > > > > > > But no one likes that one anyway. Yes. It is wrong before is a totally different element than . It is not a new version, it is a new protocol. And a new namespace. Why would we want that? That is the always returning problem with XMPP protocols – treating the namespace like an attribute. It is not an attribute, it is a part of element name. '' is different from '' the same way '' is different from ''. Namespaces give us availability to use e.g. '' element in different protocols in a different way, for a different purpose. They should not be used to give extra meaning to an existing element. We already have enough of the legacy of 'jabber:client' and 'jabber:server' namespaces used for the same element just in different contexts, which makes stanza handling complicated (I am just in the pain of trying to handle that properly in pyxmpp2)… I guess single XEP should never be allowed to define more than one XML namespace. Namespaces are meant to help avoid name conflicts. Why would one specification conflict with itself? Versioned namespaces make sense only when we throw the old specification away and create a new one when the same elements have different meaning or schema. > >> 3. More features: > >> > >> > >> > >> > > > > This one breaks existing dialback error implementations, but not > > general dialback implementations. This one doesn't seem particularly > > harmful, compared to (2), and I'll go along with the majority if it's > > what's deemed sensible. > > #3 is more consistent with what we do in service discovery. IMHO that's > a good thing. I like this too. In addition to the regular diallback feature announcement. In fact it could be a new element in the old dialback namespace. No need for another namespace for use with the same extension. IMHO this would make sense: (two features announced) or this: (one feature with an extra option announced), but not adding a new element in a new namespace instead of the already known element. Greets, Jacek
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
My apologies for the delayed reply, I was at the IESG retreat when this was sent and I've been catching up on email ever since. On 5/2/11 1:55 AM, Philipp Hancke wrote: > On Tue, 26 Apr 2011, Peter Saint-Andre wrote: > [...] Changelog: To reduce the possibility of confusion, harmonized the protocol sections so that they show only the first dialback negotiation from Originating Server to Receiving Server. (psa) >>> >>> Congratulations, you managed not to fix the from/to bugs, despite having >>> a patch ( http://hancke.name/jabber/ilovelovelovebugsinexamples.patch ) >>> >>> This is ridiculous. >> >> I posted to this list about two possible paths: (1) describe only the >> unidirectional dialback negotiation from Originating Server to Receiving >> Server, or (2) describe the bidirectional dialback negotiation (the >> negotiation that authorizes the Originating Server to generate stanzas >> from the Sender Domain, and the negotiation that authorizes the >> Receiving Server to generate stanzas from the Target Domain). >> I said that I leaned heavily toward documenting only the unidirectional >> negotiation. Your patch assumed that we just needed to do a bit of >> cleanup to option #2, whereas I decided to choose option #1 because it >> is confusing to describe both directions. >> Thus your patch did not really apply. > > Example 5: > send:from='target.tld' > ... > > Example 6: > recv:from='sender.tld' > ... > > Example 7: > recv:from='target.tld' > > My patch, which changed the 'from' attribute in example 7 to > 'sender.tld' did not apply? > > Narrative version: the server that sent a from target.tld > in example 5 receives a stanza from target.tld in example 7? > > Using your words this is a "serious bug". Copy and paste error. Fixed in source control. >> That is not ridiculous, that is a disagreement. > > I have not (yet) reviewed the changes or commented on them. You commented that it is ridiculous. >> However, if you think it is ridiculous to choose option #1 (despite the >> fact that this is what RFC 3920 did), then we can continue to discuss >> the topic on this list, you can appeal to the XMPP Council, > > I had evaluated option #1 when writing the initial 0.4. It is much less > useful when debugging because typically dialback happens twice during a > bidirectional session and with this option it is harder to figure out > which packet belongs to which session. Option #1 is what we had in RFC 3920. That doesn't seem to have prevented implementation and deployment of server dialback. > I would not advise people who can not deal with the confusion perceived > by you in the (corrected) version 0.8 to attempt implementing dialback, > because what happens on the wire is even more complicated. At one time I worked on extremely detailed server-to-server examples in XEP-0238 (XMPP Protocol Flows for Inter-Domain Federation) but it was a lot of work to maintain. > So I do not see why now, after 18 months, this change is necessary nor > why it has to be done over the weekend. Because mixing the directions in the middle of the examples is extremely confusing. Now, I'd be fine with adding another *complete* set of examples showing the negotiation in direction 2, resulting in sections like this: 2. "Protocol Flow for Negotiating Connection From sender.tld to target.tld" (i.e., the current Sections 2.1 and 2.2) 3. "Directionality" (i.e., the current Section 2.3) 4. "Protocol Flow for Negotiating Connection From target.tld to sender.tld" (new section similar to 2.1 and 2.2 but in the other direction, so we don't leave direction 2 as an exercise for the reader as in RFC 3920) However, I continue to think that mixing direction 1 and direction 2 in the current Sections 2.1 and 2.2 is way too confusing. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 5/18/11 12:58 AM, Philipp Hancke wrote: >> Version 0.10 of XEP-0220 (Server Dialback) has been released. > > For the record: > I disapprove this version because it still contains "serious bugs" > (example 7) You are right that example 7 has a copy and paste error... This: recv: Should be: recv: Fixed in source control. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
Version 0.10 of XEP-0220 (Server Dialback) has been released. For the record: I disapprove this version because it still contains "serious bugs" (example 7) and is published without my approval as an author.
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
Peter Saint-Andre wrote: [...] The concern that Jack Erwin raised with me is that putting child elements in stream features will lead people to expect more of the same, such as: This is not going to happen. If DNA or "advanced piggybacking" require special signalling then it makes no sense to reuse dialback as a framework. D-W-D for example does not require signalling.
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On Tue, May 17, 2011 at 9:20 PM, Peter Saint-Andre wrote: >>> 1. Child elements as in 0.9: >>> >>> >>> >>> >>> >>> >> >> I'm not opposed to this, I think. It has the advantage of not breaking >> the existing implementations. > > The concern is, what happens when someone adds new sub-features in the > future? Hopefully we wouldn't spec new features without versioning and start seeing interoperable implementations prior to realising in the future :) >>> 3. More features: >>> >>> >>> >>> >> >> This one breaks existing dialback error implementations, but not >> general dialback implementations. This one doesn't seem particularly >> harmful, compared to (2), and I'll go along with the majority if it's >> what's deemed sensible. > > #3 is more consistent with what we do in service discovery. IMHO that's > a good thing. Yes, #3 is what we have previously agreed is the Right Thing to do with features. In this case we didn't, and implementations sprouted up and were deployed before we noticed, so it's a question now of whether the pragmatic thing is to use what we have, or to break implementations and maintain spec-hygiene. /K
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 5/17/11 2:07 PM, Kevin Smith wrote: > On Tue, May 17, 2011 at 9:00 PM, Peter Saint-Andre wrote: >> So let's talk about solutions. >> >> 1. Child elements as in 0.9: >> >> >> >> >> >> > > I'm not opposed to this, I think. It has the advantage of not breaking > the existing implementations. The concern is, what happens when someone adds new sub-features in the future? Do we really want something like the following? Envision what that would be like for something like XEP-0060: It seems preferable to take the same approach for stream features that we take for normal features (disco), which is why I proposed versioning of stream feature namespaces. But Dave has me mostly convinced that there is a better way. >> 2. Versioning: >> >> >> >> >> >> > > This one *does* break all existing implementations of dialback, which > seems to me like a bad thing. Bad copy and paste, should be: But no one likes that one anyway. >> 3. More features: >> >> >> >> > > This one breaks existing dialback error implementations, but not > general dialback implementations. This one doesn't seem particularly > harmful, compared to (2), and I'll go along with the majority if it's > what's deemed sensible. #3 is more consistent with what we do in service discovery. IMHO that's a good thing. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On Tue, May 17, 2011 at 9:00 PM, Peter Saint-Andre wrote: > So let's talk about solutions. > > 1. Child elements as in 0.9: > > > > > > I'm not opposed to this, I think. It has the advantage of not breaking the existing implementations. > 2. Versioning: > > > > > > This one *does* break all existing implementations of dialback, which seems to me like a bad thing. > 3. More features: > > > > This one breaks existing dialback error implementations, but not general dialback implementations. This one doesn't seem particularly harmful, compared to (2), and I'll go along with the majority if it's what's deemed sensible. /K
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 5/17/11 12:04 PM, Dave Cridland wrote: > On Tue May 17 18:55:22 2011, Peter Saint-Andre wrote: >> On 5/17/11 11:51 AM, Dave Cridland wrote: >> >> > Versioning is *nearly* always the wrong thing to do. >> >> http://mail.jabber.org/pipermail/standards/2008-September/019763.html > > In the message you quote, I continued: > > """ > Our namespace versioning is not versioning of the protocol in this > sense, because that would imply that "urn:xmpp:features:dialback:0" is a > subset of "urn:xmpp:features:dialback:1", whereas no such assertion > exists - the two are entirely unrelated from a protocol standpoint, and > any similarity is merely in the familial sense - they're likely to have > both been specified in the same document at different times. > > But - crucially - no compatibility is asserted; indeed the precisely > opposite assertion is made: the two protocols are mutually incompatible. > """ > > This matches what I originally proposed in the message of mine you have > cited above: > > """ > urn:xmpp:protoname:1 > > That last portion we'll treat as a version number. Any time we cause > incompatibility between versions of the XEP, we update it. (Note, > that's not "every new XEP"). > """ > > Note use of the word "incompatibility". The use of the term "version" > is, I agree, confusing, but my point here is that by changing the > namespace version number, we're actually both signalling, and causing, > an incompatible variant of the protocol. Not necessarily incompatible in all ways, but perhaps in some. > I don't think the variants of dialback in discussion here are > incompatible within the subset currently defined. Point taken. So let's talk about solutions. 1. Child elements as in 0.9: 2. Versioning: 3. More features: Given that dialback errors are indeed a feature unto themselves (albeit compatible with RFC3920-dialback), #3 might be the best approach. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On Tue May 17 18:55:22 2011, Peter Saint-Andre wrote: On 5/17/11 11:51 AM, Dave Cridland wrote: > Versioning is *nearly* always the wrong thing to do. http://mail.jabber.org/pipermail/standards/2008-September/019763.html In the message you quote, I continued: """ Our namespace versioning is not versioning of the protocol in this sense, because that would imply that "urn:xmpp:features:dialback:0" is a subset of "urn:xmpp:features:dialback:1", whereas no such assertion exists - the two are entirely unrelated from a protocol standpoint, and any similarity is merely in the familial sense - they're likely to have both been specified in the same document at different times. But - crucially - no compatibility is asserted; indeed the precisely opposite assertion is made: the two protocols are mutually incompatible. """ This matches what I originally proposed in the message of mine you have cited above: """ urn:xmpp:protoname:1 That last portion we'll treat as a version number. Any time we cause incompatibility between versions of the XEP, we update it. (Note, that's not "every new XEP"). """ Note use of the word "incompatibility". The use of the term "version" is, I agree, confusing, but my point here is that by changing the namespace version number, we're actually both signalling, and causing, an incompatible variant of the protocol. I don't think the variants of dialback in discussion here are incompatible within the subset currently defined. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On Tue, May 17, 2011 at 6:55 PM, Peter Saint-Andre wrote: > On 5/17/11 11:51 AM, Dave Cridland wrote: >> Versioning is *nearly* always the wrong thing to do. > http://mail.jabber.org/pipermail/standards/2008-September/019763.html Which does say to only increment on incompatible updates - it's not at all clear to me at the moment that adding errors is an incompatible change. /K
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 5/17/11 11:51 AM, Dave Cridland wrote: > Versioning is *nearly* always the wrong thing to do. http://mail.jabber.org/pipermail/standards/2008-September/019763.html smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On Tue May 17 18:04:43 2011, Peter Saint-Andre wrote: On 5/17/11 10:30 AM, Dave Cridland wrote: > On Tue May 17 02:14:06 2011, XMPP Extensions Editor wrote: >> Changelog: Modified stream features to incorporate versioning, thus >> removing the need for an child element; clarified a few >> points in the text. (psa) > > Interoperable implementations of dialback using child element > to indicate this capability exist; is there any reason to change the > namespace at this point aside from aesthetics? The concern that Jack Erwin raised with me is that putting child elements in stream features will lead people to expect more of the same, such as: That seems like a bad path to go down. Much better, I think, to use a mechanism we already have: protocol versioning, such as the following for old-style RFC3920 dialback (mythically version zero of the feature but we use stream headers instead), dialback-with-errors, some future dialback-with-dna, etc.: Right, thanks for the explanation, and in particular raising this on the list, I'd not seen this argument before. And that in turn explains why I've not argued vociferously against it before, which I'll now do... Versioning is *nearly* always the wrong thing to do. Our namespace versioning is not versioning of the protocol in this sense, because that would imply that "urn:xmpp:features:dialback:0" is a subset of "urn:xmpp:features:dialback:1", whereas no such assertion exists - the two are entirely unrelated from a protocol standpoint, and any similarity is merely in the familial sense - they're likely to have both been specified in the same document at different times. But - crucially - no compatibility is asserted; indeed the precisely opposite assertion is made: the two protocols are mutually incompatible. As protocols develop, however, optional features do get added, and these should be independently signalled in most cases. Sometimes it's better to signal levels, but those levels need to be designed in from the outset. An example is IMAP's relatively recent I18NLEVEL capability (See RFC 5255). If we wanted to signal levels, we should have done so earlier, and by a distinct version or level field, and absolutely not by a namespace. While in general it's better to avoid silly-states, where a server can advertise a useless combination of features, this is sometimes unavoidable. In this particular case, DNA is likely to rely upon error handling. So in this case, if servers signalled error handling by one feature, but we intended to change the namespace to signal *also* handling DNA, then we'd also need to signal the old namespace anyway, to avoid the case where older servers would cease to interoperate because the required feature is no longer found: This seems opaque, in the extreme. A less obfuscated way would be: xmlns='urn:ietf:params:xml:elephant:doormat:xmpp:these:ietf:urns:are:very:long:dna'/> But this is pretty ugly too, or at least not especially pretty. So instead, we could choose to consider error handling and DNA as suboptions of dialback, and write: ... which brings us back to what we had before this change. I think this is fine, and I specifically do not see why this is a bad thing to do, or to continue to do. In particular, this would mean that servers written now, and looking for and advertising , will continue to work, and new options will not change this. Of course, this leaves the silly-state: And here we need to define whether this is legal, and if it is, what it means. But not here, and not now. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 5/17/11 10:30 AM, Dave Cridland wrote: > On Tue May 17 02:14:06 2011, XMPP Extensions Editor wrote: >> Changelog: Modified stream features to incorporate versioning, thus >> removing the need for an child element; clarified a few >> points in the text. (psa) > > Interoperable implementations of dialback using child element > to indicate this capability exist; is there any reason to change the > namespace at this point aside from aesthetics? The concern that Jack Erwin raised with me is that putting child elements in stream features will lead people to expect more of the same, such as: That seems like a bad path to go down. Much better, I think, to use a mechanism we already have: protocol versioning, such as the following for old-style RFC3920 dialback (mythically version zero of the feature but we use stream headers instead), dialback-with-errors, some future dialback-with-dna, etc.: > To be specific, I see no behavioural changes introduced that nessecitate > a change in namespace, and the only change in the wire protocol is the > changed stream feature. From RFC 3920 to XEP-0220 we've introduced dialback errors. That seems worthy of revving the stream feature. However, if you meant that version 0.10 of XEP-0220 did not introduce any changes to the wire protocol for server dialback in comparision to version 0.9, then you are correct. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On Tue May 17 02:14:06 2011, XMPP Extensions Editor wrote: Changelog: Modified stream features to incorporate versioning, thus removing the need for an child element; clarified a few points in the text. (psa) Interoperable implementations of dialback using child element to indicate this capability exist; is there any reason to change the namespace at this point aside from aesthetics? To be specific, I see no behavioural changes introduced that nessecitate a change in namespace, and the only change in the wire protocol is the changed stream feature. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On Tue, 26 Apr 2011, Peter Saint-Andre wrote: [...] Changelog: To reduce the possibility of confusion, harmonized the protocol sections so that they show only the first dialback negotiation from Originating Server to Receiving Server. (psa) Congratulations, you managed not to fix the from/to bugs, despite having a patch ( http://hancke.name/jabber/ilovelovelovebugsinexamples.patch ) This is ridiculous. I posted to this list about two possible paths: (1) describe only the unidirectional dialback negotiation from Originating Server to Receiving Server, or (2) describe the bidirectional dialback negotiation (the negotiation that authorizes the Originating Server to generate stanzas from the Sender Domain, and the negotiation that authorizes the Receiving Server to generate stanzas from the Target Domain). I said that I leaned heavily toward documenting only the unidirectional negotiation. Your patch assumed that we just needed to do a bit of cleanup to option #2, whereas I decided to choose option #1 because it is confusing to describe both directions. Thus your patch did not really apply. Example 5: send: My patch, which changed the 'from' attribute in example 7 to 'sender.tld' did not apply? Narrative version: the server that sent a from target.tld in example 5 receives a stanza from target.tld in example 7? Using your words this is a "serious bug". That is not ridiculous, that is a disagreement. I have not (yet) reviewed the changes or commented on them. However, if you think it is ridiculous to choose option #1 (despite the fact that this is what RFC 3920 did), then we can continue to discuss the topic on this list, you can appeal to the XMPP Council, I had evaluated option #1 when writing the initial 0.4. It is much less useful when debugging because typically dialback happens twice during a bidirectional session and with this option it is harder to figure out which packet belongs to which session. I would not advise people who can not deal with the confusion perceived by you in the (corrected) version 0.8 to attempt implementing dialback, because what happens on the wire is even more complicated. So I do not see why now, after 18 months, this change is necessary nor why it has to be done over the weekend. or you can ask me to remove you from the list of authors. It is not like I currently get to review and approve new versions before publication...
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 4/26/11 1:27 AM, Philipp Hancke wrote: > On Mon, 25 Apr 2011, XMPP Extensions Editor wrote: >> Version 0.9 of XEP-0220 (Server Dialback) has been released. >> >> Abstract: This specification defines the Server Dialback protocol, >> which is used between XMPP servers to provide identity verification. >> Server Dialback uses the Domain Name System (DNS) as the basis for >> verifying identity; the basic approach is that when a receiving server >> accepts a server-to-server connection from an originating server, it >> does not process traffic over the connection until it has verified a >> key with an authoritative server for the domain asserted by the >> originating server. Although Server Dialback does not provide strong >> authentication or trusted federation and although it is subject to DNS >> poisoning attacks, it has effectively prevented most instances of >> address spoofing on the XMPP network since its development in the year >> 2000. >> >> Changelog: To reduce the possibility of confusion, harmonized the >> protocol sections so that they show only the first dialback >> negotiation from Originating Server to Receiving Server. (psa) > > Congratulations, you managed not to fix the from/to bugs, despite having > a patch ( http://hancke.name/jabber/ilovelovelovebugsinexamples.patch ) > > This is ridiculous. I posted to this list about two possible paths: (1) describe only the unidirectional dialback negotiation from Originating Server to Receiving Server, or (2) describe the bidirectional dialback negotiation (the negotiation that authorizes the Originating Server to generate stanzas from the Sender Domain, and the negotiation that authorizes the Receiving Server to generate stanzas from the Target Domain). I said that I leaned heavily toward documenting only the unidirectional negotiation. Your patch assumed that we just needed to do a bit of cleanup to option #2, whereas I decided to choose option #1 because it is confusing to describe both directions. Thus your patch did not really apply. That is not ridiculous, that is a disagreement. However, if you think it is ridiculous to choose option #1 (despite the fact that this is what RFC 3920 did), then we can continue to discuss the topic on this list, you can appeal to the XMPP Council, or you can ask me to remove you from the list of authors. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On Mon, 25 Apr 2011, XMPP Extensions Editor wrote: Version 0.9 of XEP-0220 (Server Dialback) has been released. Abstract: This specification defines the Server Dialback protocol, which is used between XMPP servers to provide identity verification. Server Dialback uses the Domain Name System (DNS) as the basis for verifying identity; the basic approach is that when a receiving server accepts a server-to-server connection from an originating server, it does not process traffic over the connection until it has verified a key with an authoritative server for the domain asserted by the originating server. Although Server Dialback does not provide strong authentication or trusted federation and although it is subject to DNS poisoning attacks, it has effectively prevented most instances of address spoofing on the XMPP network since its development in the year 2000. Changelog: To reduce the possibility of confusion, harmonized the protocol sections so that they show only the first dialback negotiation from Originating Server to Receiving Server. (psa) Congratulations, you managed not to fix the from/to bugs, despite having a patch ( http://hancke.name/jabber/ilovelovelovebugsinexamples.patch ) This is ridiculous.
Re: [Standards] UPDATED: XEP-0220 (Server Dialback)
On 06/18/2008 10:09 AM, XMPP Extensions Editor wrote: > Version 0.2 of XEP-0220 (Server Dialback) has been released. > > Changelog: [See revision history] (psa) > > Diff: http://is.gd/Akz > > URL: http://www.xmpp.org/extensions/xep-0220.html FYI, this is a major overhaul, similar to the differences between RFC 3920 and rfc3920bis -- lots more examples, detailed error flows, etc. The changelog is: * Rewrote introduction. * Provided motivating text about why dialback is used. * Added text about different federation models. * More clearly described what dialback accomplishes and what it does not accomplish. * Added explanatory text about scenarios in which Server Dialback is used and not used. * Clarified basic description of how dialback works. * Clarified discovery of dialback support. * Separated sections into subsections, as has been done for rfc3920bis and rfc3921bis. * Described the protocol flows in much greater detail. * Explained and illustrated failure cases more completely. * Clarified reuse of negotiated connections, a.k.a. piggybacking. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
