Subject: [xmpp] Followup WGLC of draft-ietf-xmpp-3921bis-12

From: Ben Campbell <[email-masked]>
Date: Mon, 23 Aug 2010 10:46:22 -0500

This is a Working Group Last Call of draft-ietf-xmpp-3921bis-12. 

*** This is a followup to the previous WGLC on the same draft. If you sent previous feedback, please comment as to whether you believe your comments have been resolved. ***

The draft is available at the following URL:

http://tools.ietf.org/html/draft-ietf-xmpp-3921bis-12

The WGLC will conclude on 30 August, 2010. Please note that this is a followup review, the WGLC period is one week rather than the usual two.  Please send your comments, including nits and "this is ready to go" type comments, to the authors and the working group.

Thanks!

Ben.

---

From: Philipp Hancke <[email-masked]>
Date: Fri, 27 Aug 2010 10:15:17 +0200

> The WGLC will conclude on 30 August, 2010. Please note that this is a followup review, the WGLC period is one week rather than the usual two.  Please send your comments, including nits and "this is…

Some feedback:

Some links in the TOC do not work, such as 3.1.1, 3.1.2, 3.1.5, 3.1.6. 
The HTML anchors exist however.

4.3.2: I think it would be better to add an interoperability note 
because of the changed 'from' of the probe.

4.4.2: (sending presence after errors): do we need a note that this 
behaviour changed (in a positive way)?

4.5.2: I think the second implementation note referring to the presence 
optimization needs to be updated.

I am not sure if I will have the time to read the whole document again, 
but a little feedback is better than no feedback at all :-)

philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 30 Aug 2010 14:38:32 -0600

Thanks for the continued feedback.

On 8/27/10 2:15 AM, Philipp Hancke wrote:
>> *** This is a followup to the previous WGLC on the same draft. If you
>> sent previous feedback, please comment as to whether you believe your
>> comments have been resolved. ***
>>
>> The WGLC will conclude on 30 August, 2010. Please note that this is a
>> followup review, the WGLC period is one week rather than the usual
>> two.  Please send your comments, including nits and "this is ready to
>> go" type comments, to the authors and the working group.
> 
> Some feedback:
> 

That's an issue with the xml2rfc tool. Besides, the canonical format is
ASCII text so we don't need to worry about anchors. ;-)

BTW, the RFC Editor might ask us to shorten the table of contents by not
showing so many levels (I'm not sure what their current policy is, but
I'll inquire).

> because of the changed 'from' of the probe.

I agree that this point was unspecified in RFC 3921. However, if we
added an interoperability note for every point that is specified in
3921bis but was unspecified in 3921, the document would be way longer
than it is already. Furthermore, what is the interop issue here?

> behaviour changed (in a positive way)?

As far as I can see, this behavior was unspecified in RFC 3921. Earlier
versions of 3921bis talked about presence errors here, but we don't need
an interoperability note about changes from one version of 3921bis to
another (once 3921bis is published as an RFC, all that will matter is
the difference between 3921 and the RFC-to-be). IMHO, naturally.

> optimization needs to be updated.

What change do you propose? I removed the word "optimization" from the
note in Section 4.4.2 because it's an open question whether the behavior
described there really is an optimization, so I'd be happy to change the
note in Section 4.5.2 so that it says something like this:

      Implementation Note: Even if the user's server does not broadcast
      the user's subsequent presence notifications to contacts who are
      offline (as described under Section 4.4.2), it MUST broadcast the
      user's unavailable presence notification; if it did not do so,
      the last presence received by the contact's server would be the
      user's initial presence for the presence session, with the result
      that the contact would consider the user to be online.

I think we also need to adjust the wording of the note in Section 4.5.3,
as follows:

   If the contact's server does not broadcast subsequent presence
   notifications to users who are offline (as described under Section
   4.4.2), it MUST also update its internal representation of which
   entities are online by noting that the user is unavailable.

> but a little feedback is better than no feedback at all :-)

Indeed!

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 31 Aug 2010 15:40:43 -0600

Philipp replied off-list, but I'm replying to him on-list regarding the
points that are relevant to the group.

On 8/31/10 9:58 AM, Philipp Hancke wrote:

> Am 30.08.2010 22:38, schrieb Peter Saint-Andre:

<snip/>

> If servers attempt to carry out the "user is in contact's roster" check
> with a full jid, assuming that the probe 'from' is always a bare jid.

AFAIK, no servers behave that way.

> If you see any way to clarify this in a short and precise way ...

Yes, I see a way.

Change:

"if the user is in the contact's roster"

to:

"if the user's bare JID is in the contact's roster"

Which is clearer anyway (and describes all implementations AFAIK).

> RFC 3921, 5.1.2. Presence Broadcast:
> [...] (3) from whom the server has not received a presence error during
> the user's session

You're right. I missed that during a quick grep of RFC 3921.

> I think we want server developers to notice and implement that change asap.

Agreed.

Here is a proposed note:

      Interoperability Note: RFC 3921 specified that the contact's
      server would check to make sure that it had not received a
      presence error from the contact; in order to provide for more
      efficient "healing" of subscription synchronization problems, this
      specification changes the behavior to use a presence stanza of
      "unsubscribe".

> WFM.

Thanks.

Peter

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

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 01 Sep 2010 08:39:15 +0200

Peter Saint-Andre wrote:
<snip/>
> Which is clearer anyway (and describes all implementations AFAIK).

perfect.

>        specification changes the behavior to use a presence stanza of

Not quite. This section is about the subsequent presence broadcast, and 
unsubscribing would be overkill (that depends on the error type actually).

What about something along the lines of
RFC 3921 specified that a user's server should not include a contact 
from whom the server has received a presence error during the user's 
session in a subsequent presence broadcast. This condition was removed 
in order to achieve a more resilient exchange of presence.

cheers

philipp