Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-3921bis-08

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 04 Aug 2010 10:44:43 -0600

On 7/28/10 5:30 PM, Florian Zeitz wrote:
> On 28.07.2010 17:29, Peter Saint-Andre wrote:
>> On 7/27/10 3:51 AM, Florian Zeitz wrote:
>>> In section 2.6.2 the first and last paragraph seem to contradict
>>> each other. One says you MUST include a ver attribute if roster
>>> versioning is supported the other says there are legitimate reasons
>>> to leave it out even though you support versioning. I also think that
>>> the last paragraph is wrong when saying that not wanting to bootstrap
>>> is a reason to leave the ver attribute out.
>>
>> I see no contradiction:
>>
>>    If a client supports roster versioning and the server to which it has
>>    connected advertises support for roster versioning as described in
>>    the foregoing section, then the client MUST include the 'ver' element
>>    in its request for the roster.
>>
>> vs.
>>
>>    Naturally, if the client does not support roster versioning or does
>>    not wish to bootstrap the use of roster versioning, it will not
>>    include the 'ver' attribute.
>>
>> So it's a question of whether the client supports roster versioning.
>>
> Basically what Kev said.
> However I still don't see how not wanting to bootstrap is a reason to
> leave the 'ver' attribute out. Either you want to bootstrap and set it
> to an empty string, or you set it to the version you currently have.
> Otherwise I think this sentence would be equivalent to "If the client
> doesn't support roster versioning, or isn't in the mood to use it, it
> will not include the 'ver' attribute"...

I changed MUST to SHOULD, so I think that addresses your concern.

>>> Section 4.3.1 says »The server MUST NOT send a probe to a contact if
>>> the user is not subscribed to the contact's presence [...], unless
>>> the user has sent directed presence to the contact and has received
>>> presence information in return.«. I don't think having received
>>> presence information is actually needed as a requirement here.
>>
>> I think it's worth discussing that more. I'll bring it up in the WG
>> meeting on Thursday (along with other open issues -- I'll post to the
>> list about that separately).
>>
> See my other mail.

My working copy now has this text:

      Implementation Note: Although presence probes are intended for
      sending to contacts (i.e., entities to which a user is
      subscribed), a MAY send a presence probe to the full JID of an
      entity from which the user has received presence information
      during the current session.

>>> Section 4.4.2 (same for 4.5.2) requires the type of the last
>>> received presence not to have been "unsubscribe" and a subscription
>>> of from or both. Is there really a case (that I'm missing) where the
>>> last received presence was type="unsubscribe", but we have a
>>> subscription state of "from" or "both"?
>>
>> Well, 'from' means the contact is subscribed to the user (i.e., there is
>> a subscription *from* the contact to the user), so if the contact sends
>> 'unsubscribe' to the user then the user's server shouldn't send outbound
>> presence anymore.
>>
> Sure, I'm not saying that is wrong. However I would have expected that
> in response to the 'unsubscribe' the server would also have changed
> 'from' to 'none' and 'both' to 'to'... Maybe I'm just confused here.

Ah, I see your point. I've changed that text to:

   2.  The last presence stanza received from the contact during the
       user's presence session was not of type "unsubscribe" (because
       the user's server would then have changed the subscription state
       to either "none" or "to"; see Section 3.3 and Appendix A).

>>> Section 4.6.4: I think text similar to that provided in section
>>> 4.6.3 would be better here.
>>
>> Please clarify.
>>
> 4.6.3 dealing with server handling of inbound directed presence just
> says, directed presence is no different to normal presence to a server.
> If I didn't miss something the same goes for clients. But 4.6.4 instead
> choose to copy the text that is already present in 4.2.4, 4.4.4 and
> 4.5.4 (which is a lot of duplicates too if I may say that).

True. I've changed the duplicate text so that those sections refer to
the first instance.

>>> Section 8: We no longer specify that higher priority == more
>>> available at all. Shouldn't this at least be a suggestion for a
>>> possible algorithm? This also needs to go into Appendix E I think.
>>
>> Could you clarify exactly what you are suggesting?
> Just so I'm sure I'm not completely out of line let me get in some more
> detail than may be needed.
> Current practice on most servers (which was also mandated by rfc3921
> AFAICT) is to treat resources with a higher priority value as more
> available and send messages addressed to the bare JID to the highest
> priority resource.
> 3921bis has changed that in two ways.
> 1. Sending messages to all only resources is not allowed
> 2. Availability is not determined by presence, but instead chosen by a
> implementation specific algorithm.
> What I suggest is:
> a) That Section 8 should provide the "highest priority resource is most
> available" behaviour as example for one such algorithm (or even present
> it as a sensible default).

Done.

> b) Appendix E should mention this changes

Done.

Peter

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