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

From: Ben Campbell <[email-masked]>
Date: Tue, 13 Jul 2010 14:50:24 -0500

This is a Working Group Last Call of draft-ietf-xmpp-3921bis-08. The draft is available at the following URL:

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

The WGLC will conclude on 27 July, 2010. Please send your comments, including nits and "this is ready to go" type comments, to the authors and the working group.

Please note that this WGLC will end during the week of IETF 78. Although it does end prior to the scheduled XMPP meeting on that Thursday, it would be extremely helpful if reviewers send feedback as early in the WGLC cycle as they can. Given the author's other life as an Apps AD, I expect he will be extremely busy during the week of the IETF meeting.

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 20 Jul 2010 16:14:12 -0500

Hi everyone,

We're half-way through this WGLC, and I don't think we've seen any feedback. Does that mean the draft is perfect? If so, please send feedback to that effect ;-)

Seriously, though, we need more reviews one way or another to make progress on this.

Thanks!

Ben.

On Jul 13, 2010, at 2:50 PM, Ben Campbell wrote:

> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Kevin Smith <[email-masked]>
Date: Wed, 21 Jul 2010 09:16:04 +0100

> We're half-way through this WGLC, and I don't think we've seen any feedback. Does that mean the draft is perfect? If so, please send feedback to that effect ;-)

Sorry - I'm so behind on mail I'd not realised the WGLC had started.
I'm starting a review today, I'm hoping this'll get the ball rolling.

/K

---

From: Kevin Smith <[email-masked]>
Date: Wed, 21 Jul 2010 17:14:22 +0100

> I'm starting a review today, I'm hoping this'll get the ball rolling.

And I'm done. Now for others :)

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Jul 2010 10:20:44 -0600

On 7/21/10 10:14 AM, Kevin Smith wrote:
>>> We're half-way through this WGLC, and I don't think we've seen
>>> any feedback. Does that mean the draft is perfect? If so, please
>>> send feedback to that effect ;-)
>> 
>> Sorry - I'm so behind on mail I'd not realised the WGLC had
>> started. I'm starting a review today, I'm hoping this'll get the
>> ball rolling.
> 

Thank you, Kevin!

Now I need to start entering issues in the tracker... ;-)

Peter

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

---

From: Florian Zeitz <[email-masked]>
Date: Tue, 27 Jul 2010 03:51:00 +0200

On 13.07.2010 21:50, Ben Campbell wrote:
> Ben

Following is my feedback for the draft. I suspect that it will overlap
with some handled/mentioned issues, but unfortunately don't have time to
check for that right now.

Section 1.5 has »some examples in this document use the form "&#x...."
as a notational device«. Because people tend to assume things I'd
suggest explicitly noting that this is only a notational device and not
to be sent over the wire.

Section 2.3.3 says »The value of the 'name' attribute is greater than a
server-configured limit.«. I'd suggest replacing "greater" with
"longer". Same for the text concerning the text about the <group/> element.

Later in 2.3.3 it says to »process the roster set as best as possible«,
which sounds wrong to me.

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.

Section 3.1.2 says »If the presence subscription request cannot be
locally delivered or remotely routed (e.g., [...] the local contact does
not exist[...]), then the user's server MUST return an appropriate error
stanza to the user.«
while 3.1.3 says »If the contact does not exist, then the contact's
server MUST automatically return a presence stanza of type
"unsubscribed" to the user.«
Unless I missread something that means that a non-existing account on
the local server will yield a error reply while a non-existing account
on a remote server will yield a "unsubscribed" presence. Is this intended?

Section 3.2.2: s/outound/outbound/

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.

Section 4.3.2 bullet 4 has »Here the 'from' addresses are the bare JIDs
of each available resource.« this needs to be "full JIDs" AFAICT.

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"?

Section 4.6.4: I think text similar to that provided in section 4.6.3
would be better here.

Section 4.7.2.1: calling the value of the <show/> element "not
human-readable" seems a bit of a stretch to me. I think the intention
here was something to the effect of "The character data of the <show/>
element is not meant for presentation to a user".

Section 4.7.2.3 should specify if the altered priority is also send to
the contacts if the server chooses to override the priority provided by
the client. I'd think it should be.

Section 5.1: "at least several" seems like a strange thing to say. Maybe
just s/at least//... Also the second paragraph is missing a ")" at the
very end.

Section 7 example 11: s/hvae/have/

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.

- --
Florian Zeitz

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Jul 2010 17:29:22 +0200

On 7/27/10 3:51 AM, Florian Zeitz wrote:

> Following is my feedback for the draft. I suspect that it will
> overlap with some handled/mentioned issues, but unfortunately don't
> have time to check for that right now.
> 
> Section 1.5 has »some examples in this document use the form
> "&#x...." as a notational device«. Because people tend to assume
> things I'd suggest explicitly noting that this is only a notational
> device and not to be sent over the wire.

Fixed:

   Following the "XML Notation" used in [IRI] to represent characters
   that cannot be rendered in ASCII-only documents, some examples in
   this document use the form "&#x...." as a notational device to
   represent Unicode characters (e.g., the string "&#x0159;" stands for
   the Unicode character LATIN SMALL LETTER R WITH CARON); this form is
   definitely not to be sent over the wire in XMPP systems.

> Section 2.3.3 says »The value of the 'name' attribute is greater than
> a server-configured limit.«. I'd suggest replacing "greater" with 

Fixed per previous list conversation.

> Later in 2.3.3 it says to »process the roster set as best as
> possible«, which sounds wrong to me.

Fixed per previous list conversation.

> 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.

> locally delivered or remotely routed (e.g., [...] the local contact
> does not exist[...]), then the user's server MUST return an
> appropriate error stanza to the user.« while 3.1.3 says »If the
> contact does not exist, then the contact's server MUST automatically
> return a presence stanza of type "unsubscribed" to the user.« Unless
> I missread something that means that a non-existing account on the
> local server will yield a error reply while a non-existing account on
> a remote server will yield a "unsubscribed" presence. Is this
> intended?

I've provisionally removed the bullet point about 'unsubscribed', per
list discussion.

> Section 3.2.2: s/outound/outbound/

Fixed.

> 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).

> Section 4.3.2 bullet 4 has »Here the 'from' addresses are the bare
> JIDs of each available resource.« this needs to be "full JIDs"
> AFAICT.

Fixed.

> 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.

> Section 4.6.4: I think text similar to that provided in section
> 4.6.3 would be better here.

Please clarify.

> human-readable" seems a bit of a stretch to me. I think the
> intention here was something to the effect of "The character data of
> the <show/> element is not meant for presentation to a user".

Fixed.

> Section 4.7.2.3 should specify if the altered priority is also send
> to the contacts if the server chooses to override the priority
> provided by the client. I'd think it should be.

Fixed.

> Section 5.1: "at least several" seems like a strange thing to say.
> Maybe just s/at least//... Also the second paragraph is missing a ")"
> at the very end.

I've changed "at least several" to "multiple".

> Section 7 example 11: s/hvae/have/

Fixed.

> 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?

Thank you very much for your review.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Jul 2010 18:02:33 +0200

> list about that separately).

I've thought about this further. The current text says:

   The server MUST NOT
   send a probe to a contact if the user is not subscribed to the
   contact's presence (i.e., if the contact is not in the user's roster
   with the 'subscription' attribute set to a value of "to" or "both"),
   unless the user has sent directed presence to the contact and has
   received presence information in return.

Well, I probe because I want to know your presence, so whether you have
sent presence to me already seems relevant to the decision. Now, you
could argue that it doesn't matter whether I have sent presence to you!
But the last clause seems quite relevant (and in fact both seem good
because directed presence is a reciprocal arrangement).

Peter

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

---

From: Kevin Smith <[email-masked]>
Date: Wed, 28 Jul 2010 17:58:32 +0100

> So it's a question of whether the client supports roster versioning.

Almost - the "Or does not wish to bootstrap the use of roster
versioning" gives an instance where a client supports versioning, but
doesn't including 'ver' - which the previous paragraph prohibits.

> list about that separately).

Right (sorry if I missed the other thread, posting here in case I
forget) - I think we at least don't want to prohibit sending probes
between users that have directed presence, whatever the outcome.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Jul 2010 19:01:31 +0200

> doesn't including 'ver' - which the previous paragraph prohibits.

So that's essentially changing MUST to SHOULD, no? :)

/psa

---

From: Kevin Smith <[email-masked]>
Date: Wed, 28 Jul 2010 18:01:56 +0100

> because directed presence is a reciprocal arrangement).

Does this open issues with things like "sent directed presence to the
contact...when?" and whether this has to be per-session or lifetime or
etc?.

I'm happy for you to say no :)

/K

---

From: Kevin Smith <[email-masked]>
Date: Wed, 28 Jul 2010 18:02:33 +0100

> So that's essentially changing MUST to SHOULD, no? :)

That'd seem to do the trick.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Jul 2010 19:04:09 +0200

> I'm happy for you to say no :)

Oh it is most definitely per-session, because directed presence always
is. I've added "during the current presence session" to the end of that
sentence.

Peter

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

---

From: Kevin Smith <[email-masked]>
Date: Wed, 28 Jul 2010 18:06:56 +0100

> is. I've added "during the current presence session" to the end of that

I thought about this some more, and I realised that I don't understand
why we need to prohibit probes. Why do we need to prohibit probes? :)

/K

---

From: "Peter Saint-Andre" <[email-masked]>
Date: Wed, 28 Jul 2010 15:59:32 -0600 (MDT)

> why we need to prohibit probes. Why do we need to prohibit probes? :)

This is backwards in one respect: my server mustn't answer such a probe.
Forbidding the sending of probes in this situation, while laudable (it's
none of my business what your presence is if I'm not subscribed to your
presence or if we haven't exchanged directed presence), it's a threat
without force -- what matters here is the server policy of the "probee",
not that of the "prober".

/psa

---

From: Florian Zeitz <[email-masked]>
Date: Thu, 29 Jul 2010 01:08:38 +0200

> because directed presence is a reciprocal arrangement).

Indeed, this is one of those nothing good happens after 2am things ;)
What I meant to say was "I don't think having send presence is actually
needed as a requirement here".
While it certainly makes sense to have send directed presence in both
directions I think it should suffice if the probee has send presence to
the prober for a probe to succeed.

--
Florian Zeitz

---

From: Florian Zeitz <[email-masked]>
Date: Thu, 29 Jul 2010 01:30:59 +0200

> 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"...

> list about that separately).
See my other mail. I should probably also note that I'm not going to be
present at IETF78 even though physically close. I shall however be
available in the groupchat.

> 'unsubscribe' to the user then the user's server shouldn't send outbound
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.

>> 4.6.3 would be better here.
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).

> 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).
b) Appendix E should mention this changes

> Thank you very much for your review.
Thank you as well.
FWIW the "Fixed" parts that I have removed for the sake of readability
all seemed fine.

--
Florian Zeitz

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 29 Jul 2010 08:28:27 +0200

> the prober for a probe to succeed.

Yes, that might make sense. I'll make sure we discuss this during the
meeting today.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 29 Jul 2010 17:33:27 +0200

> not that of the "prober".

Right.

For the probing server, I propose 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.

I think the existing text about the behavior of the probed server is fine:

   If the contact's server receives a presence probe addressed to a full
   JID of the contact, the server MUST NOT return presence information
   about any resource except the resource specified by the 'to' address
   of the probe.  Rules #1 and #2 for a bare JID probe apply equally to
   the case of a full JID probe.  If there is a resource matching the
   full JID and (a) the probing entity has authorization via a presence
   subscription to see the contact's presence or (b) the contact has
   sent directed available presence to the probing entity, then the
   server MUST return an available presence notification, which SHOULD
   communicate only the fact that the resource is available (not
   detailed information such as the <show/>, <status/>, <priority/>, or
   presence extensions).

/psa