Subject: [xmpp] Reviewing bis8-bis11 changes

From: Kevin Smith <[email-masked]>
Date: Fri, 13 Aug 2010 12:17:24 +0100

I've been reviewing
http://tools.ietf.org/rfcdiff?url1=draft-ietf-xmpp-3921bis-08.txt&url2=draft-ietf-xmpp-3921bis-11.txt
(hoorah for providing an arbitrary query string and it working as
expected)
Comments below. Sorry for any that should have been picked up on
previous review.

* Changes are largely good, thanks Peter.

* " It is possible for a contact to be in a user's roster both with a	
			"Pending Out" sub-state and with a subscription pre-approval.	
			Because the <item/> element cannot have two instances of the 'ask'	
			attribute (one with a value of "subscribe" and one with a value of	
			"subscribed"), the server SHALL indicate such a state by including a	
			single 'ask' attribute with a value of "subscribe subscribed"."

This surprised me a little (I missed this proposal on the list
somehow). This seems like a backwards-incompatible change, and so
worries me.

* " Implementation Note: If the account has no available resources	
			when the inbound subscribed notification is received, a server MAY	
			keep a record of the notification (ideally the complete presence	
			stanza) and then deliver the notification when the account next	
			has an available resource. This behavior provides more complete	
			signalling to the user regarding the reasons for the roster change	
			that occurred while the user was offline."

This isn't a problem, but doesn't actually do much useful, as the
client that logs in can be a different client from the one that logged
out. I guess the first client could pop up a window saying "Hey, they
approved you". I've talked myself out of complaining about this now,
but am leaving the text here so others can avoid the same confusion.

* Pre-approval: I've not opened the thread on this yet. It worries me
somehow, but I can't quite put my finger on it.

* "When the contact's client receives presence from the user, the	
	proceed as follows:		following behavior is suggested:
...
2. If the user is not in the contact's roster but the contact and
the user are actively exchanging message or IQ stanzas, SHOULD
display the presence information in the user interface for that..."

Yes, I know the lead-up says its suggested and doesn't use
caps-keywords, and so that means that the following SHOULD isn't
really a SHOULD, because it's only a SHOULD if you're following the
suggestions - despite this, can we get rid of the SHOULD? I think
simply deleting the word should scan ok.

* " As an optimization, if the subscription type is "both", then the
   server MAY send subsequent presence notifications to a contact only
   if the contact is online according to the user's server.  That is, if
   the user's server never received a positive indication that the
   contact is online in response to the presence probe it sent to the
   contact or if the last presence stanza it received from the contact
   during the user's presence session was of type "unavailable", the
   user's server MAY opt to not send subsequent presence notifications
   from the user to the contact."

As with the other optimisation (not responding to probes) I'm not
comfortable with having this suggested in the spec, given that we know
there are situations in which this will break. As with the other one,
I suggest we say SHOULD send, leaving us a little wriggle-room, and
then write another spec (either RFC or XEP) that lists lossy
presence-based performance enhancements, and discusses the failure
cases associated with them.

* "If the 'to' address is the bare JID, the receiving server
      SHOULD deliver the message to all of the recipient's available
      resources with non-negative presence priority; if the 'to' address
      is a full JID and there is a matching resource, the server MUST
      deliver the message to that resource; otherwise the server MUST
      either silently ignore the message or return an error (see
      Section 8).
"

I think this leaves wriggle room for the server to say "Well, I SHOULD
deliver to all resources, but I'm going to decide to send it to none
of them", where I think it really means "SHOULD deliver ...all
...resources, but MUST deliver to some of them!"

* "The inclusion of the <thread/> element is OPTIONAL for messages of
   type "normal", "headline", and "groupchat", and RECOMMENDED for
   messages of type "chat"."

Do we really want this? Given that we have relatively little
deployment experience of threads being used sensibly, it seems that
leaving it OPTIONAL makes sense - SHOULD send thread is a significant
departure from the current norm.

* " If the domainpart of the address contained in the 'to' attribute of
   an outbound stanza does not match a configured domain of the server
   itself, then the server MUST attempt to route the stanza to the
   remote domain."

Should this be ", subject to local security policies, "?

* "o  If there is more than one resource with a non-negative presence
      priority then the server SHOULD either (a) deliver the message to
      the "most available" resource or resources (according to the
      server's implementation-specific algorithm, e.g., treating the
      resource or resources with the highest presence priority as "most
      available") or (b) deliver the message to all of the non-negative
      resources."

Given the current trends etc etc, I think there may be merit here in
informally recommending that it's delivered to all available
resources. Much opposition to this and I'll step down, though, it's a
whim.

* " For an IQ stanza of type "get" or "set", if the intended recipient	
			does not share presence with the requesting entity either by means	
			of a presence subscription of type "both" or "from" or by means of	
			directed presence, then the server SHOULD NOT deliver the IQ	
			stanza but instead SHOULD return a <service-unavailable/> stanza	
			error to the requesting entity. This policy helps to prevent	
			presence leaks (see Section 11).
		"

Is this new? I think I may have missed this.

* "	If no available resource or connected resource exactly matches...
    For a message stanza of type "normal", "groupchat", or "headline",	
			the server MUST either (a) silently ignore the stanza or (b) return	
			an error stanza to the sender, which SHOULD be <service-	
			unavailable/>."

For normal too? That seems wrong. "normal" messages MUST NOT be
silently ignored, shirley?

Sorry this was long - I was anticipating having fewer comments, or I
would have used several mails to make it easier to track.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 16 Aug 2010 16:57:58 -0600

> somehow). This seems like a backwards-incompatible change, and so

See other thread (it's all related to subscription pre-approval).

> out. 

Sure.

> I guess the first client could pop up a window saying "Hey, they
> approved you". 

Correct. The client doesn't need to grovel through the roster and diff
the new version against what it had cached, instead it can depend on the
"subscribed" coming from the server.

> I've talked myself out of complaining about this now,

It's not all that special, really, but it provides more helpful
information to the client.

> somehow, but I can't quite put my finger on it.

See other thread.

> simply deleting the word should scan ok.

That "SHOULD" was mistakenly not deleted along with the others. Fixed.

> cases associated with them.

I think this is more appropriate as an interoperability note:

      Interoperability Note: If the subscription type is "both", some
      existing server implementations send subsequent presence
      notifications to a contact only if the contact is online according
      to the user's server (that is, if the user's server never received
      a positive indication that the contact is online in response to
      the presence probe it sent to the contact, the user's server does
      not send subsequent presence notifications from the user to the
      contact).  This behavior is perceived to save bandwidth, since
      most presence subscriptions are bidirectional and many contacts
      will not be online at any given time.

I agree that it would be appropriate to define such "optimizations"
(including their measured benefits and likely costs) in separate
specifications.

> ...resources, but MUST deliver to some of them!"

Good catch, I hadn't seen that wiggle room. This is better:

      ... SHOULD deliver the message to all of the recipient's available
      resources with non-negative presence priority and MUST deliver the
      message to at least one of those resources...

> departure from the current norm.

Fixed per other list thread.

> Should this be ", subject to local security policies, "?

Yes, it should. Fixed.

> resources. Much opposition to this and I'll step down, though, it's a

All available resources, even those with negative presence priority?
That would indeed be novel.

> Is this new? I think I may have missed this.

I think you're the one who proposed that. :)

Or perhaps it was Justin Karneges...

> silently ignored, shirley?

Good question. I think we need some discussion about that one. In part
this gets back to the presence leak threat. What would you suggest for
handling of a normal message sent to a full JID with a non-existent
resource? I don't think it's right to say the server MUST return an
error (presence leak!). We could say that if the sender is authorized to
know the presence of the intended recipient then MUST return an error,
otherwise silently ignore. But some might argue that the right thing is
delivering the message to the most available resource or to all
non-negative resources, i.e., treating it as if it had been addressed to
the bare JID. Perhaps we need to start a separate thread about this
issue so that it doesn't get lost here...

> would have used several mails to make it easier to track.

No worries, feedback is appreciated in whatever form!

Peter

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