Subject: [xmpp] Fwd: Re: [jdev] Server responses to resource conflicts

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 17 Sep 2010 11:53:32 -0600

FYI.

-------- Original Message --------
Subject: Re: [jdev] Server responses to resource conflicts
Date: Fri, 17 Sep 2010 11:52:54 -0600
From: Peter Saint-Andre <[email-masked]>
Reply-To: Jabber/XMPP software development list <[email-masked]>
To: Jabber/XMPP software development list <[email-masked]>

Will, you make some good points. I will add some stronger wording to
rfc3920bis on this point after IETF Last Call.

On 9/16/10 2:38 AM, Will Thompson wrote:
> Hi,
> 
> <http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-14#section-7.6.2.2>
> specifies three legal server responses to a client trying to connect
> with an already-connected resource:
> 
> 1. Assign the new client a fresh resource;
> 2. Boot the old connection, granting the resource to the new client;
> 3. Refuse the new connection.
> 
> It recommends 1, which is what (e.g.) Google Talk implements (well, they
> always randomize, but it's equivalent in this case ;-)). I was under the
> impression that no-one did 3, but I discovered that Openfire apparently
> does. <https://bugzilla.gnome.org/show_bug.cgi?id=629768>
> 
> I don't really think behaviour 3 is very useful. Maybe this is a
> function of being interested in mobile stuff, but I believe that the
> most common reason for trying to connect with an already-connected
> resource is recovering from a loss of connectivity. As the above-linked
> bug shows, behaviour 3 means you can't reconnect until the original
> connection times out.
> 
> So, I think the third behaviour should be strongly discouraged, with
> this rationale. (I suspect making it illegal is not going to fly now.) I
> guess the client can work around this behaviour by retrying with a
> different resource, but this doesn't have the nice property of cleaning
> up dead connections.
> 
> (Obviously the One True Way to recover from a loss in connectivity is
> XEP-0198, but deployed servers don't all implement this.)
> 
> Regards,
_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [email-masked]
_______________________________________________

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 17 Sep 2010 12:03:49 -0600

The current text is:

   Which of these the server does is up to the implementation,
   although it is RECOMMENDED to implement case #1.

I suggest changing it to:

   Which of these the server does is up to the implementation,
   although it is RECOMMENDED to implement case #1 and NOT
   RECOMMENDED to implement case #3.

---

From: Waqas Hussain <[email-masked]>
Date: Sun, 19 Sep 2010 07:15:29 +0500

On Thu, Sep 16, 2010 at 1:38 PM, Will Thompson
<[email-masked]> wrote:
> specifies three legal server responses to a client trying to connect with an
> already-connected resource:
>

This is configurable in Prosody. We allow kick_old (#2, default),
kick_new (#3), random (#1), increment (also #1, works by attaching an
incrementing number to the given resource).

> I don't really think behaviour 3 is very useful. Maybe this is a function of
> being interested in mobile stuff, but I believe that the most common reason
> for trying to connect with an already-connected resource is recovering from
> a loss of connectivity. As the above-linked bug shows, behaviour 3 means you
> can't reconnect until the original connection times out.
>

Do you think #3 it's still useless if the server knows the old
resource is still connected and responsive (e.g., as tested by sending
an XMPP ping - I think M-Link did this)?

> So, I think the third behaviour should be strongly discouraged, with this
> rationale. (I suspect making it illegal is not going to fly now.) I guess
> the client can work around this behaviour by retrying with a different
> resource, but this doesn't have the nice property of cleaning up dead
> connections.
>

I'd like extra text in
http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-14#section-8.3.3.2
saying a client shouldn't blindly keep trying to reconnect if it has
been disconnected with a <conflict/> (to prevent two clients from
fighting over a resource).

--
Waqas Hussain

---

From: Kevin Smith <[email-masked]>
Date: Sun, 19 Sep 2010 08:56:10 +0100

> an XMPP ping - I think M-Link did this)?

M-Link checks if the old resource is still active, then either kills
the inactive old resource and lets the new session in with the
requested resource, or leaves the existing active resource intact and
assigns a new resource for the new session.

/K

---

From: Dave Cridland <[email-masked]>
Date: Mon, 20 Sep 2010 11:31:16 +0100

On Sun Sep 19 08:56:10 2010, Kevin Smith wrote:
> function of

Right - we do (1) or (2) depending on the results of a ping on the  
existing session.

In fact, we originally did (3) - ie, refusing the new jid - and we  
changed to this much more complex method because:

a) It was very badly handled by a number of clients. Many clients  
(and I include popular, widely deployed clients) treated a failure to  
bind a resource as a fatal error, and told the user it was an  
"authorization error". I think we're very close to a MUST NOT refuse  
a resource binding.

b) Purely using a random resource - ie, (1) - caused an increase in  
ghosting effects on remote servers, something that's visible today in  
servers that do so. Clients do, however, handle a server-overidden  
resource, so this is a reasonable option.

c) Purely discarding the old session - option (2) - opens the  
possibility of two clients configured for auto-reconnect causing a  
"ping-pong" or "yoyo" effect between them. This can be highly  
undesirable, as session setup is costly for servers. Yoyo can still  
occur on M-Link, but it's limited to pairs of clients which have a  
latency in excess of 10 seconds, which is pretty rare, even with  
mobile clients.

We use a ping timeout of 10 seconds for conflicted existing sessions,  
incidentally. I found this struck a reasonable balance between making  
it so short we'd hit yoyo effects, and making it so long it was  
irritating if you were genuinely conflicting. I'm hoping that for the  
case where the original session is lost and you are, genuinely,  
reconnecting, then 198 will handle this in a much shorter timeframe.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 20 Sep 2010 11:41:18 -0600

> an XMPP ping - I think M-Link did this)?

I don't see #3 as positively harmful, but the server needs to know what
it's doing or have that kind of knowledge to make productive use of the
option.

> fighting over a resource).

I agree that we need to say a few words about that, but I think it
belongs in Section 7.6.2.2.

http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-14#section-7.6.2.2

I propose the following tweaks to Section 7.6.2.2, including some
terminology adjustments, a paragraph describing case #1, and the text
Waqas requested regarding client handling of case #3...

###

7.6.2.2.  Conflict

   If there is a currently connected client whose session has the
   resourcepart being requested by the connecting client, the server
   MUST do one of the following:

   1.  Not accept the resourcepart provided by the connecting client but
       instead override it with a resourcepart that the server
       generates.

   2.  Disallow the resource binding attempt of the connecting client
       and maintain the existing session of the currently connected
       client.

   3.  Terminate the session of the currently connected client and allow
       the resource binding attempt of the connecting client.

   Which of these the server does is up to the implementation, although
   it is RECOMMENDED to implement case #1 and NOT RECOMMENDED to
   implement case #3.

   In case #1, the server returns an <iq/> stanza of type "result" to
   the connecting client, where the <jid/> child of the <bind/> element
   contains XML character data that indicates the full JID of the
   connecting client, including the resourcepart that was generated by
   the server.

   S: <iq id='wy2xa82b4' type='result'>
       <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
         <jid>
      [email-masked]/balcony 4db06f06-1ea4-11dc-aca3-000bcd821bfb
         </jid>
       </bind>
      </iq>

   In case #2, the server MUST send a <conflict/> stanza error in
   response to the resource binding attempt of the connecting client but
   maintain the XML stream so that the connecting client has an
   opportunity to negotiate a non-conflicting resourcepart (i.e., the
   connecting client MUST choose a different resourcepart before making
   another attempt to bind a resource).

   S: <iq id='wy2xa82b4' type='error'>
        <error type='modify'>
          <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
        </error>
      </iq>

   In case #3, the server MUST send a <conflict/> stream error to the
   currently connected client and return an IQ stanza of type "result"
   (indicating success) in response to the resource binding attempt of
   the connecting client.

   S: <iq id='wy2xa82b4' type='result'>
        <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
          <jid>
            [email-masked]/balcony
          </jid>
        </bind>
      </iq>

   If the current resource receives a <conflict/> stream error, it MUST
   NOT attempt to blindly request the same resourcepart when
   reconnecting but instead MUST choose a different resourcepart to use
   in the resource binding aspect of the stream negotiation process.

###

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave Cridland <[email-masked]>
Date: Mon, 20 Sep 2010 21:57:27 +0100

On Mon Sep 20 18:41:18 2010, Peter Saint-Andre wrote:
> although
I think this needs expansion:

Although servers have the choice of implementing any of these  
strategies, #3 is NOT RECOMMENDED because it can lead to an  
unterminated cycle of two clients effectively disconnecting each  
other. #2 is also NOT RECOMMENDED, as deployment experience has shown  
this to have poor support from clients, although it does work.  
Servers MAY change their behaviour depending on the state of the  
existing connection, including pinging it via [XEP-0199] to test  
connectivity.

>           <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>

And, perhaps, here:

Note: This error is known to be badly supported; clients are known to  
treat it as an authentication error, and have been observed to  
discard cached credentials, etc.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 20 Sep 2010 15:17:22 -0600

On 9/20/10 2:57 PM, Dave Cridland wrote:
> strategies, #3 is NOT RECOMMENDED because it can lead to an unterminated
> cycle of two clients effectively disconnecting each other. #2 is also
> NOT RECOMMENDED, as deployment experience has shown this to have poor
> support from clients, although it does work. Servers MAY change their
> behaviour depending on the state of the existing connection, including
> pinging it via [XEP-0199] to test connectivity.

That's better, thanks. Tweaked slightly in my working copy:

   Although servers have the choice of implementing any of these
   strategies, #3 is NOT RECOMMENDED because it can lead to a
   neverending cycle of two clients effectively disconnecting each
   other. #2 is also NOT RECOMMENDED, because deployment experience has
   shown this to have poor support from clients (although it does work).
   Therefore #1 is the RECOMMENDED approach.  Servers MAY change their
   behavior depending on the state of the existing connection (e.g., as
   determined via connectivity checking methods such as [XEP-0199]).

> treat it as an authentication error, and have been observed to discard
> cached credentials, etc.

WFM.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Florian Zeitz <[email-masked]>
Date: Tue, 21 Sep 2010 01:30:20 +0200

>> treat it as an authentication error, and have been observed to discard

I'm actually rather unhappy with this. It sounds somewhat like a free
pass for clients to be broken. I'm especially uncomfortable with having
normative text discouraging #2 and #3 just based on current client
support (which is subject to change). In fact I'm quite surprised #3
would frequently cause unwanted behavior since this has been default in
most server implementations I know...
I'd prefer if we just leave this in an implementation note mentioning
that it is only "at the time of writing" and try to get the offending
clients fixed.

--
Florian Zeitz

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 21 Sep 2010 12:08:30 -0600

> that it is only "at the time of writing" and try to get the offending

Hi Florian, you make a good point.

How about the following?

###

7.6.2.2. Conflict

   1.  Override the resourcepart provided by the connecting client with
       a server-generated resourcepart.

   2.  Disallow the resource binding attempt of the connecting client
       and maintain the session of the currently connected client.

   Which of these the server does is a matter for implementation or
   local service policy.

   Implementation Note: Experience has shown that Case #3 can lead to a
   neverending cycle of two clients effectively disconnecting each
   other, although it can be appropriate in some deployment scenarios
   or if the server knows (e.g., based on connectivity checking methods
   such as [XEP-0199]) that the currently connected client is not
   actively using its connection.

   [...]

###

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Florian Zeitz <[email-masked]>
Date: Tue, 21 Sep 2010 23:14:53 +0200

>    actively using its connection.

That sounds reasonable to me.
However I suspect we are not checking for active use of the stream (a
silent stream could certainly become active again and cause the
described endless loop), but for a broken stream.

--
Florian Zeitz

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 21 Sep 2010 15:21:40 -0600

> On 21.09.2010 20:08, Peter Saint-Andre wrote:

<snip/>

> described endless loop), but for a broken stream.

Ah yes, our old friend the silent peer. :)

This is better:

   Implementation Note: Experience has shown that Case #3 can lead to a
   neverending cycle of two clients effectively disconnecting each
   other, although it can be appropriate in some deployment scenarios
   or if the server knows that the currently connected client has a
   dead connection or broken stream as described under Section 4.5.

(Where Section 4.5 = "Handling of Silent Peers".)

/psa

---

From: Dave Cridland <[email-masked]>
Date: Wed, 22 Sep 2010 00:20:51 +0100

On Tue Sep 21 00:30:20 2010, Florian Zeitz wrote:
> pass for clients to be broken.

There's a trade-off to be made between knowing what behaviour clients  
will do if not broken, and knowing what clients actually do in the  
field. This is not least because we really want these documents to  
progress to Draft, and that means avoiding behaviour which doesn't  
actually work very well.

#2 is, in my experience, leading to a reduced interoperability that  
may be acceptable in some cases, and that suggests a SHOULD NOT to my  
eyes - that is, that ignoring this advice may to lead to  
interoperability issues unless the full implications are weighed  
carefully.

>  I'm especially uncomfortable with having

It's been observed on occasion to happen in live deployments,  
sometimes with the effect of tying up the server. This denies service  
to legitimate clients, causing an interoperability issue. It is not a  
foregone conclusion, and almost certainly won't reach this state on a  
non-LAN service, but nevertheless this suggests a SHOULD NOT, as  
above.

> that it is only "at the time of writing" and try to get the  

The other issue is that really, there's no need to "fix" the clients  
to cope with a complex problem that is best solved by a server doing  
connectivity checks, and #1 - and can be also solved by a naïve  
server doing simply #1.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 21 Sep 2010 21:02:16 -0600

> progress to Draft, and that means avoiding behaviour which doesn't

Given that we're not trying to progress to Draft at this time, it might
be best to not make strong recommendations on this point pending further
interoperability testing over the next 12 months, then make such
recommendations in 3920ter (yes, I think we'll publish such a document,
although I expect the diff from 3920bis to 3920ter will be *much*
smaller than the diff from 3920 to 3920bis).

> #2 is, in my experience, leading to a reduced interoperability that may
> be acceptable in some cases, and that suggests a SHOULD NOT to my eyes -
> that is, that ignoring this advice may to lead to interoperability
> issues unless the full implications are weighed carefully.

It would be good to document and discuss the interoperability issues you
have experienced.

> It's been observed on occasion to happen in live deployments, sometimes
> with the effect of tying up the server. This denies service to
> legitimate clients, causing an interoperability issue. It is not a
> non-LAN service, but nevertheless this suggests a SHOULD NOT, as above.

The matter is complicated by the fact that #3 is the traditional
behavior going back to jabberd 0.x/1.x in 1999/2000. For all I know
there might even be automated client applications that depend on this
behavior (not that I'm recommending such a dependency).

> The other issue is that really, there's no need to "fix" the clients to
> cope with a complex problem that is best solved by a server doing
> connectivity checks, and #1 - and can be also solved by a naïve server
> doing simply #1.

Simple clients, complex servers? Are you some kind of old-fashioned
Jabberista? ;-)

My conclusion from this discussion so far is that I don't yet see
consensus on whether to make stronger recommendations in 3920bis because
we don't have detailed interoperability feedback. Thus I am inclined to
keep the text in 3920bis fairly weak, but to encourage us to gather
evidence that would enable us to make strong recommendations 12+ months
from now when we try to progress to Draft Standard.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave Cridland <[email-masked]>
Date: Wed, 22 Sep 2010 09:19:28 +0100

> Simple clients, complex servers? Are you some kind of old-fashioned

Any complexity, anywhere, erodes interoperability, and variance in  
behaviour oozes complexity.

Maybe I'm just jaded from seeing years and years of discussions about  
IMAP where the variance is very high (a deliberate choice I believe),  
leading to endless discussions about what a client *might* see, and  
what combinations of choices actually work, with no guidance in the  
specifications to aid the implementor.

Clients have to deal with servers overriding their supplied resource  
for a number of reasons anyway, the fact that this can also be used  
to resolve conflicting resource bind requests is, to a client,  
immaterial - existing services, such as Google Talk, consistently  
override every resource bind request, so a client which cannot handle  
that case will be suffering significant interoperability problems  
anyway.

Therefore, as a logical consequence, servers which resolve conflicts  
by using this protocol feature have a higher chance of interop, and  
moreover always will.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2010 14:58:54 -0600

On 9/22/10 2:19 AM, Dave Cridland wrote:
> leading to endless discussions about what a client *might* see, and what
> combinations of choices actually work, with no guidance in the
> Clients have to deal with servers overriding their supplied resource for
> a number of reasons anyway, the fact that this can also be used to
> resolve conflicting resource bind requests is, to a client, immaterial -
> existing services, such as Google Talk, consistently override every
> resource bind request, so a client which cannot handle that case will be
> suffering significant interoperability problems anyway.
> 
> Therefore, as a logical consequence, servers which resolve conflicts by
> using this protocol feature have a higher chance of interop, and
> moreover always will.

OK, in my final attempt at tweaking this text, I have produced this:

###

7.6.2.2.  Conflict

   If there is a currently-connected client whose session has the
   resourcepart being requested by the newly-connecting client, the
   server MUST do one of the following (which of these the server does
   is a matter for implementation or local service policy, although
   suggestions are provided below).

   1.  Override the resourcepart provided by the newly-connecting client
       with a server-generated resourcepart.

       This behavior is encouraged, because it simplifies the resource
       binding process for client implementations.

   2.  Disallow the resource binding attempt of the newly-connecting
       client and maintain the session of the currently-connected
       client.

       This behavior is neither encouraged nor discouraged, despite the
       fact that it was implicitly encouraged in RFC 3920; however, note
       that handling of the <conflict/> error described below is
       unevenly supported among existing client implementations, which
       often treat it as an authentication error and have been observed
       to discard cached credentials when receiving it.

   3.  Terminate the session of the currently-connected client and allow
       the resource binding attempt of the newly-connecting client.

       Although this was the traditional behavior of early XMPP server
       implementations, it is now discouraged because it can lead to a
       neverending cycle of two clients effectively disconnecting each
       other; however, note that this behavior can be appropriate in
       some deployment scenarios or if the server knows that the
       currently-connected client has a dead connection or broken stream
       as described under Section 4.5.

   [...]

###

I don't think this text merits much more attention, but other folks
might disagree...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Kevin Smith <[email-masked]>
Date: Wed, 22 Sep 2010 22:08:26 +0100

> I don't think this text merits much more attention, but other folks

I'm happy with that text (My preference is strongly for either 1) or
the smart 1)+3) if there's a timeout as the sensible things to do).

/K

---

From: Florian Zeitz <[email-masked]>
Date: Wed, 22 Sep 2010 23:50:11 +0200

> the smart 1)+3) if there's a timeout as the sensible things to do).
Seconded. I think this text should address both my and Dave Cridland's
concerns.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2010 17:16:09 -0600

> Seconded. I think this text should address both my and Dave Cridland's

If this text meets with Dave's approval and there are no other comments
or objections, I'll post -16 with this text so that our esteemed Chairs
can request IETF Last Call.

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave Cridland <[email-masked]>
Date: Thu, 23 Sep 2010 08:35:31 +0100

> can request IETF Last Call.

Oh, this meets with my approval. Sorry for dragging it out. :-)

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 23 Sep 2010 05:40:05 -0600

> Oh, this meets with my approval. Sorry for dragging it out. :-)

No worries.

I'll push out revised specs today or tomorrow.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Waqas Hussain <[email-masked]>
Date: Thu, 23 Sep 2010 18:37:17 +0500

> I'll push out revised specs today or tomorrow.

Do we have text for what a client should do?

Personally I think
a. clients shouldn't specify a resource themselves, unless they have a
good reason to
b. if they do specify a resource, it should be unique
c. if they are reconnecting after a disconnect, they should specify
the resource they last had

Of the original three ways the server can deal with a conflict, I'm
personally in favor of #3+#1, followed by #3.

#1 alone leads to ghosts. In my experience, ghosts are a far more
common problem than two clients fighting over a resource. If a client
wants a specific resource, a server should assume that the client
knows what it's doing, unless the server knows better (by pinging the
old resource, etc). A smart server can detect a fight, and do #1 only
in that case.

Aside: The -bis drafts linked from http://xmpp.org/internet-drafts/
are giving me Wordpress's "Page not found" page.

--
Waqas Hussain

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 23 Sep 2010 14:53:10 -0600

> Do we have text for what a client should do?

Not yet. Do folks think we need it? I sense that we could argue about
this topic for quite a while, because IMHO the XMPP community doesn't
have settled opinions about what's right here.

> a. clients shouldn't specify a resource themselves, unless they have a

Then we'll need to define what the good reasons are. :-)

> b. if they do specify a resource, it should be unique

Unique for the current sessions or for all future sessions? And how
shall uniqueness be guaranteed?

> the resource they last had

What if the client was disconnected with a <conflict/> stream error? In
that case we're recommending that the client *not* ask for the same
resourcepart.

I'd be happy leaving out any suggestions or recommendations on this
matter, but maybe that's because spec-writer fatigue is setting in and I
just want to be done with changes to 3920bis. ;-)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ben Schumacher <[email-masked]>
Date: Thu, 23 Sep 2010 15:13:41 -0600

On 9/23/10 2:53 PM, Peter Saint-Andre wrote:
> What if the client was disconnected with a<conflict/>  stream error? In

The XSF (is it a faux-paus to mention the XSF on an IETF mailing list?) 
already had best practices documents for client writers -- this seems 
like a fine place to spell out these guidelines. Perhaps these could 
live on the Wiki, if they aren't already there. The XMPP-tradition has 
always been to be flexible and allow implementations to make their own 
decisions in these areas.

An interested party could expound on the different choices available to 
client writers and the reasons some of those choices might be made in 
such a document, but I don't feel that sort of exposition really belongs 
in a specification of the standard.

Cheers,
Ben

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 23 Sep 2010 15:22:08 -0600

> The XSF (is it a faux-paus to mention the XSF on an IETF mailing list?)

By no means. You'll notice that the bis specs have plenty of pointers to
various XEPs.

> live on the Wiki, if they aren't already there. 

That would be http://wiki.xmpp.org/

> The XMPP-tradition has

I'd go farther and suggest that even folks working within the XSF's
standards process would have a difficult time coming to consensus on
informational guidelines for client developers, who as you note are a
somewhat individualistic bunch -- which might be why the XSF hasn't
easily come to consensus on things like message threading (XEP-0201) and
some aspects of chat state notifications (XEP-0085). Trying to add such
guidelines to rfc3920bis might be an even bigger challenge.

Perhaps folks who care about this topic could start out writing a XEP
and if consensus emerges on this and other topics, we could consider
folding some of the resulting recommendations in 3920ter when the time
comes (just as we did with 3920bis/3921bis via XEPs 190, 192, 193, 201,
and 237).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Matthew Wild <[email-masked]>
Date: Mon, 27 Sep 2010 21:41:06 +0100

On 23 September 2010 22:13, Ben Schumacher <[email-masked]> wrote:
> already had best practices documents for client writers -- this seems like a
> fine place to spell out these guidelines. Perhaps these could live on the
> Wiki, if they aren't already there. The XMPP-tradition has always been to be
> flexible and allow implementations to make their own decisions in these
> areas.
>

Indeed, though choosing a resource identifier has security (kind of)
implications. I disagree with Peter that the XMPP community doesn't
have a clear direction on resource identifiers. Both new and existing
clients are moving towards requesting resource identifiers from the
server, and this is a good thing (for starters it prevents conflicts,
and presence leaks).

Prior to this clients were in the habit of shipping with default
resources like "Home", "Laptop", or the name of the client, which made
it easy to probe a list of common resources to see if someone was
online. Few clients are sensible about responding to <iq> requests
from entities not on the user's roster (indeed I suspect there are
times that ignoring such requests could be problematic).

However all this said, I think 3920bis has the necessary text in place
already, as a security note in section 7.4. It essentially instructs
clients to use strong resource identifiers or to let the server do it
for them. Although the latter approach would also magically solve
conflicts, I don't see that we *need* to make such a change to
recommend it now, in this document.

Matthew

(PS. Sorry for the late reply - I've been without internet for a few days)

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 27 Sep 2010 15:19:14 -0600

> recommend it now, in this document.

As you might recall, we had a long discussion about the security
properties of server-generated random resourceparts 3+ years ago on the
[email-masked] list (well before creation of the second
instantiation of the IETF's XMPP WG). A summary is here:

http://mail.jabber.org/pipermail/standards/2007-May/015426.html

I think we incorporated the results of that discussion into 3920bis
(modified in accordance with some subsequent discussion on this list),
so I'm not seeing any further action items at this time.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/