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

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 01 Sep 2010 08:11:54 -0600

On 9/1/10 12:39 AM, Philipp Hancke wrote:
> Peter Saint-Andre wrote:

<snip/>

>>>>> 4.4.2: (sending presence after errors): do we need a note that this
>>>>> 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.
>>>
>>> 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".
> 
> 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.

That's better. In fact the current text (in -12) is slightly inaccurate,
because if the user's server has received a presence stanza of
"unsubscribe" then the subscription state would have already changed by
the time it sends subsequent presence notifications. Therefore I think
this is even better in Section 4.4.2:

###

   Upon receiving a presence stanza expressing updated availability, the
   user's server MUST broadcast the full XML of that presence stanza to
   the contacts who are in the user's roster with a subscription type of
   "from" or "both".

      Interoperability Note: RFC 3921 specified that the user's server
      would check to make sure that it had not received a presence error
      from the contact before sending subsequent presence notifications;
      that rule has been removed because this specification uses
      presence stanzas of type "unsubscribe" (not "error") to solve
      subscription synchronization problems, in part because such
      stanzas change the contact's subscription state in the user's
      roster to either "none" or "to" (see Section 3.3 and Appendix A),
      thus obviating the need for the error check.

###

The same applies (mutatis mutandis) to the sending of unavailable
presence notifications in Section 4.5.2.

Peter

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

---

From: Ben Campbell <[email-masked]>
Date: Wed, 1 Sep 2010 17:41:20 -0500

Hi Everyone,

We're extending the WGLC on this until 7 September 2010, in hopes of getting reviews from more people. Remember, if you think it's ready to go, please send feedback to that effect. If you gave feedback in the previous WGLC, please comment on whether your earlier feedback has been addressed.

Thanks!

Ben.

On Aug 23, 2010, at 10:46 AM, Ben Campbell wrote:

> 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.
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 06 Sep 2010 19:22:43 +0200

Peter Saint-Andre wrote:
[...]
>        thus obviating the need for the error check.

It took me a while to understand why I do not like that. I have no idea 
how to fix that, but I can try to explain the problem at least and hope 
that you will magically fix it :-)

When you think 'presence error', you probably have the following stanza 
in mind (3921, 5.5 example 6):
<presence
     type='error'
     from=[email-masked]'
     to=[email-masked]/orchard'>
   <error type='cancel'>
     <gone xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
</presence>
In that case it is reasonable for romeo not to include mercutio in any 
subsequent presence broadcast.

However, when I think 'presence error' and subsequent presence broadcast 
I think of this:
<presence
     type='error'
     from=[email-masked]'
     to=[email-masked]/orchard'>
   <error type='wait'>
     <remote-server-timeout xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
</presence>
generated by the example.net server which is temporarily unable to 
connect to the example.org server.

Usually, when that happens, the example.org server is unable to send 
stanzas to the example.net server, too (although I remember situations 
where communication worked in one direction).
Now, if the communication is reestablished romeo will not send presence 
updates to mercutio and mercutio will not send presence updates to romeo.
Even though this is a race condition, I think I have seen that more 
often than <gone/> presence errors.

cheers

philipp

---

From: Matthew Wild <[email-masked]>
Date: Tue, 7 Sep 2010 13:32:37 +0100

> We're extending the WGLC on this until 7 September 2010, in hopes of getting reviews from more people. Remember, if you think it's ready to go, please send feedback to that effect. If you gave feed…

Thanks for the extension. I had a 5 hour train journey yesterday, and
took a printed 3921bis-12 with me, as punishment for missing the its
first WGLC. I've managed to review half (55 pages) of it, the other
half I'll review on my journey back tomorrow, then I'll write up my
feedback in the evening - just so you know that it's coming.

It's mostly ok so far, though I've found some things that may need
clarification/discussion (I don't have the list I made on me right
now).

Thanks,
Matthew

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 07 Sep 2010 07:55:11 -0600

> connect to the example.org server.

But Section 4.4.2 discusses errors that example.net (the user's server)
would receive from example.org (the contact's server), not errors that
example.net would generate and send to a user at example.net. Yes, the
user's client might care about such presence errors (remote server not
found might indicate that the user mistyped the domain name for a
contact), but the user's server is not going to receive any kind of
useful errors from the contact's server -- only presence stanzas of type
"subscribe", "subscribed", "unsubscribe", and "unsubscribed". Therefore
I think my proposed text is just fine regarding the behavior of the
user's server.

Peter

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

---

From: Philipp Hancke <[email-masked]>
Date: Tue, 07 Sep 2010 16:53:24 +0200

Peter Saint-Andre wrote:
[...]

> example.net would generate and send to a user at exampe.net. Yes, the

So the RFC 3921 rule was about remote bounces only?
I usually consult the jabberd 1.4.3 source code when the RFCs do not 
make sense. It did not make this distinction between local bounce and 
remote bounce:
     /* if a presence packet bounced, remove from the A list */
(somewhere in mod_presence.c)

In fact, I do not think the responsible module (SM) can determine if the 
bounce was generated by another module (s2s) of the server itself or by 
the contact's server.

btw: A is the list of availables, so actually jabberd1.4.3 was using the 
"optimization"

> contact), but the user's server is not going to receive any kind of

No chance of mistyping if the subscription exists :-)

> I think my proposed text is just fine regarding the behavior of the

Sure. I am just arguing that the interop note should be shorter:
Interoperability Note: RFC 3921 specified that the user's server
would check to make sure that it had not received a presence error
from the contact before sending subsequent presence notifications;
that rule has been removed.

philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 07 Sep 2010 09:37:16 -0600

> bounce was generated by another module (s2s) of the server itself or by

The rule in RFC 3921 was quite underspecified. However, the XMPP RFCs do
not discuss *at all* any internal operations within an XMPP server,
whether there are components within such a server that communicate
amongst themselves (bouncing packets to and fro), etc. In this context
we can talk only about a presence error that the user's server might
have received from the contact's server, not an error that the internal
session manager component might have received from the internal
server-to-server component or whatever. And, as far as I can see, in
3921bis the only presence error that the user's server might receive
from the contact's server is something related to the contact not being
found; however, in 3921bis the contact's server would not return such an
error and would instead return a presence stanza of type "unsubscribed"
(e.g., if it receives a probe from a user who is not authorized to
receive presence from the contact).

> btw: A is the list of availables, so actually jabberd1.4.3 was using the

Yes, the "A list" is the "list of contacts that are available" or (for
short) the "avails list".

> No chance of mistyping if the subscription exists :-)

Correct. In that case, there is a lack of synchronization between the
state on the user's server and the state on the contact's server. If the
contact's server returns "unsubscribed" in that case, the user's server
or the user's client will be prompted to take some sort of action (e.g.,
re-request presence authorization to "heal" the state mismatch).

> that rule has been removed.

/me shrugs

It depends on if we want to explain the reasoning or just the bare fact
that the stuff about processing presence errors has been removed.

Peter

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

---

From: Matthew Wild <[email-masked]>
Date: Thu, 9 Sep 2010 12:45:57 +0100

> feedback in the evening - just so you know that it's coming.

Here goes... I've read through the whole document, and while I've
tried to be thorough, I don't promise I haven't missed anything. Most
issues are simply editorial, though I haven't tried to categorise
everything into editorial/non-editorial because some are not
clear-cut, and therefore I entrust such decisions to the Editor :)

2.3.2: I understand its aim, but is it really necessary to enforce
that a server uses persistent storage for the roster? An example would
be a server that temporarily stores rosters in memory for SASL
ANONYMOUS users.

2.3.3: It's an error to supply duplicate groups for a contact, but the
spec doesn't mandate a particular method for group name comparison,
meaning there is no way for a client to know it is submitting
duplicate groups without testing and receiving the error. Even if the
client did this, it would not be able to tell which the offending
group(s) in the request are.

2.3.3: I'm still of the opinion that one shouldn't be able to add
one's own JID to one's roster - but I guess I missed the conclusion on
this discussion, I can live with it if we're settled on it.

3.1.4: Assumes (and, by its wording, requires) that the client has a human user.

3.2.2: After processing the unsubscribed, the spec says that a server
MUST send unavailable presence from all the user's resources. This
would constitute a presence leak if the user was not already in the
roster with a subscription of "from" or "both".

4.2.4: What is the reasoning for saying that probes MUST be sent from
the full JID? Avoiding leaks in the case of one-way subscriptions? If
so I think it would be helpful to mention this reason - since it is a
change from 3921 and has an interop note.

4.4.1: Perhaps it would be helpful to mention PEP here?

4.7.1: Conflicts with 4.3, which says clients MAY send probes - here
it says SHOULD NOT.

4.7.2.3: By saying "must include" the modified priority, even if 0 it
seems like the <priority/> element must be included, however it
already defaults to 0 when not present, so isn't simply removing it a
valid option in a server that defaults priority to 0?

5.2.2: Just a minor thing that had me read it twice - for type "error"
it says the client must inform the "sender", but to be clear this is
the sender of the original message, not the sender of the error.

7: The examples don't include roster versioning (should they? it's an
optional feature, and it may be best left out for clarity if someone
is just interested in the basic protocol flow).

7: Presence probes MUST be from the full JID.

7: Doesn't show the original presence reflected back to the sender by
the server.

8.5.2.1.1: I find the "If the only available resource" wording
confusing, in that a user may have multiple available resources with a
negative priority, in the case of which I'm not sure that the protocol
changes.

8.5.3: This is the only section on routing that mentions the
application of privacy and policy rules - perhaps this should be moved
up into 8.1?

8.5.3.2.1: I don't think there should be an easy option of silently
ignoring type="groupchat" to a non-existent resource, the error reply
is used to detect MUC ghosts quickly, and this should at least be
mentioned.

8.5.4:
   Table 1: I think the bare and full responses of type 'groupchat'
are switched in all rows. According to the text, bare should be S/E,
and though it says in the text that full for groupchat should be S/E
too, I think that should be changed to prevent the possibility of MUC
ghosts (see 8.5.3.2.1 above).

   Table 1: For type "headline", I believe the table defines sensible
handling rules, but it is at odds with the text which says S/E.

A.2: Specifies that S.N. stands for SHOULD NOT, but does not mention
M.N., used in A.2.3.

A.2.4: Question marks after "cancel pre-approval" - intentional?
Cancelling pre-approvals is mentioned in the text in 3.2.1, though I
think it would be helpful to mention it briefly in 3.4 also.

Regards,
Matthew

PS. Lots of ToC links are broken in
http://tools.ietf.org/html/draft-ietf-xmpp-3921bis-12

---

From: Matthew Wild <[email-masked]>
Date: Thu, 9 Sep 2010 13:31:41 +0100

On 9 September 2010 12:45, Matthew Wild <[email-masked]> wrote:

> change from 3921 and has an interop note.

Sorry, I meant 4.3 here (thanks to Philipp for noticing).

Matthew

---

From: Matthew Wild <[email-masked]>
Date: Thu, 9 Sep 2010 13:34:25 +0100

> Sorry, I meant 4.3 here (thanks to Philipp for noticing).

Sigh, and I of course meant "from the bare JID", not full JID.

Matthew, gone to hide until he's more awake.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 09 Sep 2010 11:39:19 -0600

On 9/9/10 5:45 AM, Matthew Wild wrote:

> Here goes... 

Thanks for the review. I'm working my way through your comments but
probably won't be able to reply until tomorrow.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 09 Sep 2010 15:33:10 -0600

Matthew, thanks for the review.

On 9/9/10 5:45 AM, Matthew Wild wrote:
>>> We're extending the WGLC on this until 7 September 2010, in hopes
>>> of getting reviews from more people. Remember, if you think it's
>>> ready to go, please send feedback to that effect. If you gave
>>> feedback in the previous WGLC, please comment on whether your
>>> earlier feedback has been addressed.
>>> 
>> 
>> Thanks for the extension. I had a 5 hour train journey yesterday,
>> and took a printed 3921bis-12 with me, as punishment for missing
>> the its first WGLC. I've managed to review half (55 pages) of it,
>> the other half I'll review on my journey back tomorrow, then I'll
>> write up my feedback in the evening - just so you know that it's
>> coming.
>> 
> 
> tried to be thorough, I don't promise I haven't missed anything.
> Most issues are simply editorial, though I haven't tried to
> categorise everything into editorial/non-editorial because some are
> not clear-cut, and therefore I entrust such decisions to the Editor
> :)
> 
> that a server uses persistent storage for the roster? An example
> would be a server that temporarily stores rosters in memory for SASL 
> ANONYMOUS users.

We hadn't considered that use case. Furthermore, I think the text "MUST
create the roster item in persistent storage" was not adjusted when we
tweaked the related text in the first paragraph of Section 2:

   When the user adds items to the roster or modifies existing items,
   if an error does not occur then the server SHOULD store that data
   unmodified if at all possible and MUST return the data it has stored
   when an authorized client requests the roster.

Therefore I propose changing the sentence in Section 2.3.2 to:

   If the server can successfully process the roster set for the new
   item (i.e., if no error occurs), it MUST create the item in the
   user's roster and proceeds as follows.

> 2.3.3: It's an error to supply duplicate groups for a contact, but
> the spec doesn't mandate a particular method for group name
> comparison, meaning there is no way for a client to know it is
> submitting duplicate groups without testing and receiving the error.

Correct. Given that string comparison methods are in flux (cf. PRECIS
WG), I don't know if we want to make a hard requirement about the one
true method to use. In particular, introducing a normative dependency on
stringprep (via the Resourceprep profile from XMPP-ADDR) means we'll
need to track changes to that spec (it should be obsoleted in the next
year or two if the PRECIS work completes successfully).

> Even if the client did this, it would not be able to tell which the
> offending group(s) in the request are.

Also true.

How problematic do you think this is? Here is how I see it:

1. It's relatively rare for a contact to be in more than one group.

2. Duplicates are easy to detect for ASCII, but more difficult to detect
for full Unicode (e.g., Folks with an "oh" vs. Fοlks with an omicron --
these are confusable but wouldn't be caught by something like Resourceprep).

3. There's no serious *interoperability* issue here because the client
can simply remove one of the groups, change one of the group names, etc.

It seems fine if we leave this up to the implementation, but if folks
think otherwise then we need to have a discussion.

> one's own JID to one's roster - but I guess I missed the conclusion
> on this discussion, I can live with it if we're settled on it.

I think the objection was "special casing is bad", and given your
previous arguments using that reasoning I couldn't disagree. :)

> 3.1.4: Assumes (and, by its wording, requires) that the client has a

Yes, there are various places in the spec where we assume that the
client software application is an interactive client, not an automated
client. We could change these to say "if the client is an interactive
client" or "human controlling the application (if any)" and so on. I'll
look into that.

> 3.2.2: After processing the unsubscribed, the spec says that a
> server MUST send unavailable presence from all the user's resources.
> This would constitute a presence leak if the user was not already in
> the roster with a subscription of "from" or "both".

Hmm. If the contact's server sends presence of type unavailable from the
bare JID then this problem goes away. That seems like the right behavior
here anyway (because at this point the user is officially unsubscribed).

> [4.3]: What is the reasoning for saying that probes MUST be sent
> from the [bare] JID? Avoiding leaks in the case of one-way
> subscriptions? If so I think it would be helpful to mention this
> reason - since it is a change from 3921 and has an interop note.

The subscription is based on the bare JID so it makes sense for the
probe to also come from the bare JID.

> 4.4.1: Perhaps it would be helpful to mention PEP here?

Sure, an informative reference to XEP-0060 and XEP-0163 seems apropos.

> 4.7.1: Conflicts with 4.3, which says clients MAY send probes - here 

I think SHOULD NOT is correct and propose the following fix to 4.3:

      Implementation Note: Presence probes SHOULD NOT be sent by a
      client because in general a client will not need to send them,
      since the task of gathering presence from a user's contacts is
      managed by the user's server.

> 4.7.2.3: By saying "must include" the modified priority, even if 0
> it seems like the <priority/> element must be included, however it 
> already defaults to 0 when not present, so isn't simply removing it
> a valid option in a server that defaults priority to 0?

Good point, I have tweaked that sentence as follows:

   The client's server MAY override the priority value provided by the
   client (e.g., in order to impose a message handling rule of
   delivering a message intended for the account's bare JID to all of
   the account's available resources); if the server does so, it MUST
   communicate the modified priority value when it echoes the client's
   presence back to itself and sends the presence notification to the
   user's contacts (because this modified priority value is typically
   the default value of zero, communicating the modified priority value
   can be done by not including the <priority/> child element).

> 5.2.2: Just a minor thing that had me read it twice - for type
> "error" it says the client must inform the "sender", but to be clear
> this is the sender of the original message, not the sender of the
> error.

How about this?

   o  error -- The message is generated by an entity that experiences an
      error in processing a message received from another entity (for
      details regarding stanza error syntax, refer to [XMPP-CORE]).  A
      client that receives a message of type "error" SHOULD present an
      appropriate interface informing the original sender regarding the
      nature of the error.

> 7: The examples don't include roster versioning (should they? it's
> an optional feature, and it may be best left out for clarity if
> someone is just interested in the basic protocol flow).

I don't see a need for modifying the examples, but I could be convinced
otherwise.

> 7: Presence probes MUST be from the full JID.

s/full/bare/ so the examples are fine.

> 7: Doesn't show the original presence reflected back to the sender
> by the server.

Fixed.

> confusing, in that a user may have multiple available resources with
> a negative priority, in the case of which I'm not sure that the
> protocol changes.

Hmm, yes. It needs to say "If all of the available resources have a
negative presence priority..."

> application of privacy and policy rules - perhaps this should be
> moved up into 8.1?

Yes, 8.1 is the right place for it.

> ignoring type="groupchat" to a non-existent resource, the error
> reply is used to detect MUC ghosts quickly, and this should at least
> be mentioned.

Isn't that a matter for XEP-0045? See below.

> 8.5.4: Table 1: I think the bare and full responses of type
> 'groupchat' are switched in all rows. According to the text, bare
> should be S/E, and though it says in the text that full for groupchat
> should be S/E too, I think that should be changed to prevent the
> possibility of MUC ghosts (see 8.5.3.2.1 above).

I used groupchat messages to illustrate the stanza processing rules in
the "dissertation on message delivery" that I sent at the end of July:

http://www.ietf.org/mail-archive/web/xmpp/current/msg01557.html

To quote:

###

Take groupchat messages as a fairly non-controversial example. Clearly
we want to deliver such messages to the user who has joined a groupchat
room. However, if the user who was in a room then went offline, it's
helpful to return an error to the chat service so that it can clean up
any "ghosts" in the room. On the other hand, it's dangerous to return an
error if the user doesn't exist when the same kind of message sent to an
existing account would not return an error (because that would enable a
directory harvesting attack).

One simple message handling rule that would meet all of the foregoing
criteria is "the server always returns an error in response to messages
of type groupchat sent to bare JIDs".

However, handling of groupchat messages sent to full JIDs is a bit more
complex. If the server delivers the message when there is an active
resource that matches the full JID but returns an error when there is no
matching full JID, then an attacker could send lots of messages to the
same account with various random resources and perhaps discover whether
the user is online. Whether the attack is practical is another matter --
the server could start to return a different error condition if it
detects such an attack from a particular JID, although the attacker
could be smart and send its messages from multiple JIDs. We need to
weigh costs and benefits, and recognize that there are legitimate
tradeoffs between functionality and security. IMHO it is more difficult
to figure out what the right tradeoffs are with respect to presence
leaks than directory harvesting attacks, which is one reason why I think
we're having trouble agreeing on the right behavior in the case of a
headline message that is sent to a full JID where no such resource is
online.

###

> handling rules, but it is at odds with the text which says S/E.

I disagree -- see the reasoning above. I agree that we might want to
define this more completely in XEP-0045.

> A.2: Specifies that S.N. stands for SHOULD NOT, but does not mention 

Added.

> think it would be helpful to mention it briefly in 3.4 also.

It's described in the implementation note at the end of Section 3.4.2:

      Implementation Note: A client can cancel a pre-approval by sending
      a presence stanza of type "unsubscribed", as described more fully
      under Section 3.2.  In this case the user's server would send a
      roster push to all of the user's interested resources with the
      'approved' attribute removed.

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

Yep, those will be fixed by the RFC Editor.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 09 Sep 2010 18:35:58 -0600

Several further suggestions inline...

> client" or "human controlling the application (if any)" and so on. I'll

I propose changing that paragraph to:

   When an interactive client receives a subscription request, it MUST
   present the request to the natural person controlling the client
   (i.e., the "contact") for approval, unless the contact has explicitly
   configured the client to automatically approve or deny some or all
   subscription requests.  An automated client that is not controlled by
   a natural person will have its own application-specific rules for
   approving or denying subscription requests.

> here anyway (because at this point the user is officially unsubscribed).

More feedback would be appreciated regarding that proposal.

> probe to also come from the bare JID.

I propose changing the note in 4.3 to:

      Interoperability Note: RFC 3921 specified that probes are sent
      from the full JID, not the bare JID (a rule which was changed
      because subscriptions are based on the bare JID).  Some existing
      implementations send from the full JID instead of the bare JID.

/psa

---

From: Matthew Wild <[email-masked]>
Date: Fri, 10 Sep 2010 01:50:16 +0100

>   user's roster and proceeds as follows.

+1.

> think otherwise then we need to have a discussion.

Given the obvious difficulties in solving this for now, I don't
consider it a major issue.

> previous arguments using that reasoning I couldn't disagree. :)

Ah yes, special casing is very bad :)

And this is exactly the problem. In XMPP you already have an implicit
subscription to your own account - the server will send you presence
for your resources, and you are a trusted entity, etc.

If we are to allow having yourself in your roster, it means that to
behave sensibly you would have to add checks to see if the current JID
being processed (as part of a presence/PEP broadcast for example) is
the JID of the roster's owner - thus the special casing.

I don't think it's a major issue, just something I'm not particularly fond of.

> here anyway (because at this point the user is officially unsubscribed).

Agreed - though I don't think presence from bare JID was defined in
392x originally, so this could conceivably cause interop issues with
older clients/servers.

Agreed.

>      managed by the user's server.

Seems fine to me (though I'm not primarily a client developer).

>   can be done by not including the <priority/> child element).

+1, thanks.

>      appropriate interface informing the original sender regarding the

+1.

> I don't see a need for modifying the examples, but I could be convinced

I'm convinced to keep them the as-is if you're inclined to.

> s/full/bare/ so the examples are fine.

Yes, pretend I never wrote this - I don't know what happened :)

> negative presence priority..."

Agreed, thanks.

> define this more completely in XEP-0045.

Ok, that's fine - but the table is still at odds with the text in
these cases, no?

>      'approved' attribute removed.

Thanks, I missed that - looks good. The question marks in the table
are not intentional though, are they?

Matthew

---

From: Matthew Wild <[email-masked]>
Date: Fri, 10 Sep 2010 01:54:47 +0100

+1.

> More feedback would be appreciated regarding that proposal.

Given, see my other email.

+1, thanks.

Regards,
Matthew

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 09 Sep 2010 20:23:37 -0600

> consider it a major issue.

That's how I see it for now, but others might disagree.

> I don't think it's a major issue, just something I'm not particularly fond of.

And neither am I -- IMHO adding yourself to your own roster is dumb,
useless, and unnecessary. But I don't see any active harm in it, either...

> 392x originally, so this could conceivably cause interop issues with

Another option: the contact's server could send the "unavailable"
notifications (from all full JIDs) before sending the "unsubscribed" --
that seems preferable because the user is still subscribed to the
contact when the unavailable notifications are sent, then the contact's
server sends the "unsubscribed" as the coup de grace. :)

> Seems fine to me (though I'm not primarily a client developer).

Yes, we'll ping some of them to see what they think. :)

> Ok, that's fine - but the table is still at odds with the text in

Let's roll the videotape...

Section 8.5.2.1.1 (which defines the delivery rule for messages sent to
a bare JID when available resources exist) has this:

   For a message stanza of type "groupchat", the server MUST NOT deliver
   the stanza to any of the available resources but instead MUST return
   a stanza error to the sender, which SHOULD be <service-unavailable/>.

Section 8.5.2.2.1 (same, but no available resources) has:

   For a message stanza of type "groupchat", the server MUST return an
   error to the sender, which SHOULD be <service-unavailable/>.

Section 8.5.3.1 (full JID, resource matches) has:

   o  For a message stanza, the server MUST deliver the stanza to the
      resource.

Section 8.5.3.2 (full JID, no resource matches) has:

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

The relevant parts of the table from Section 8.5.4 are as follows...

   Table 1: Message Delivery Rules

   +--------------------------------+
   | Condition        |  Groupchat  |
   +--------------------------------+
   | ACCOUNT DOES NOT EXIST         |
   |  bare            |      E      |
   |  full            |     S/E     |
   +--------------------------------+
   | ACCOUNT EXISTS, BUT NO ACTIVE  |
   | RESOURCES                      |
   |  bare            |      E      |
   |  full (no match) |     S/E     |
   +--------------------------------+
   | 1+ NEGATIVE RESOURCES BUT ZERO |
   | NON-NEGATIVE RESOURCES         |
   |  bare            |      E      |
   |  full match      |      D      |
   |  full no match   |     S/E     |
   +--------------------------------+
   | 1 NON-NEGATIVE RESOURCE        |
   |  bare            |      E      |
   |  full match      |      D      |
   |  full no match   |     S/E     |
   +--------------------------------+
   | 1+ NON-NEGATIVE RESOURCES      |
   |  bare            |      E      |
   |  full match      |      D      |
   |  full no match   |     S/E     |
   +--------------------------------+

The text and the table seem consistent to me, and also preserving of the
privacy and security principles laid out in the "dissertation" I sent on
July 31 (and incorporated into the draft soon thereafter).

> are not intentional though, are they?

They were intentional (to indicate that processing the "unsubscribed"
might result in cancelling the pre-approval), but I've removed them
because there is no state change in that case. So now each of those
cells in the table has:

   |  no state change [1]  |

Where the footnote is:

      [1] This event can result in cancelling of a subscription pre-
      approval, as described under Section 3.4.

I note in passing that we're kind of dancing around the question of
whether adding or removing a subscription pre-approval is a state change
(on par with something like "None+Pending-Out"), but in the spec I'm
saying that they are not subscription state changes. That's my story and
I'm sticking to it. :)

/psa

---

From: Dave Cridland <[email-masked]>
Date: Fri, 10 Sep 2010 09:28:21 +0100

> I don't think it's a major issue, just something I'm not  
FWIW, we found that there were sufficient loopholes allowing a user  
to add their own jid (one customer discovered the joy of sending  
subscription requests to themselves, for instance) that we found it  
easier to special case the handling of one's own jid in the roster,  
rather than special casing every point of addition to it.

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: Fri, 10 Sep 2010 06:12:04 -0600

On 9/10/10 2:28 AM, Dave Cridland wrote:

> (one customer discovered the joy of sending
> subscription requests to themselves, for instance)

Wow, that's sad.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 10 Sep 2010 13:14:02 +0100

> > subscription requests to themselves, for instance)

No.

What's sad is that they rejected the request.

Dave.

---

From: Matthew Wild <[email-masked]>
Date: Fri, 10 Sep 2010 13:36:23 +0100

> That's how I see it for now, but others might disagree.

I hope silence == consent in this case, then :)

> useless, and unnecessary. But I don't see any active harm in it, either...

I'll respond to Dave's post on this in a minute.

> server sends the "unsubscribed" as the coup de grace. :)

That does seem a more sensible order perhaps. Though the other issue
is that the text doesn't say to send this presence only if the contact
was actually subscribed to the user. I know sending unsubscribed
suggests that there was indeed a subscription - but pre-approvals give
a good example of how that might go wrong now. The client may think it
has pre-approved a contact, and now wishes to remove the pre-approval.
It does this by sending unsubscribed, but another client has already
at the same moment done the same - this causes the server to route the
unsubscribed and also send unavailable presence from the user's
resources, despite the remote contact never having been subscribed in
the first place.

> Let's roll the videotape...

Ok, thanks for bearing with me - I comprehend.

So now, what do you think about modifying the last sentence of text
prior to the table in 8.5.4:

    The '/' character stands for "or" and denotes a choice between
multiple possible actions. The
    server should observe the rules given in section 8.1 when choosing
which action to take for
    a particular message.

>      approval, as described under Section 3.4.

That works, thanks.

> saying that they are not subscription state changes. That's my story and

Yes, I noted the same - I decided to let you get away with it :)

Matthew

---

From: Matthew Wild <[email-masked]>
Date: Fri, 10 Sep 2010 14:05:18 +0100

On 10 September 2010 09:28, Dave Cridland <[email-masked]> wrote:
> FWIW, we found that there were sufficient loopholes allowing a user to add
> their own jid (one customer discovered the joy of sending subscription
> requests to themselves, for instance) that we found it easier to special
> case the handling of one's own jid in the roster, rather than special casing
> every point of addition to it.
>

We had exactly the same problems, though it seems you concluded the
opposite to us. There are only two places a JID may get into a user's
roster... when loading from disk, and when adding an item - so we
check in both places, and all currently works fine.

Matthew

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 10 Sep 2010 08:17:20 -0600

> check in both places, and all currently works fine.

As far as I can see, RFC 3921 did not have this prohibition -- we added
it to 3921bis at some point because we thought it was a good idea.
Again, I don't see any active harm in allowing a user to add its own JID
to the roster. Do you disagree? Do you return an error on the roster
set? How do you handle a presence stanza of type "subscribe" when the
'to' address specifies the user's own JID?

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 10 Sep 2010 08:47:08 -0600

<snip/>

>>>>> 3.2.2: After processing the unsubscribed, the spec says that
>>>>> a server MUST send unavailable presence from all the user's
>>>>> resources. This would constitute a presence leak if the user
>>>>> was not already in the roster with a subscription of "from"
>>>>> or "both".
>>>> 
>>>> Hmm. If the contact's server sends presence of type unavailable
>>>> from the bare JID then this problem goes away. That seems like
>>>> the right behavior here anyway (because at this point the user
>>>> is officially unsubscribed).
>>> 
>>> Agreed - though I don't think presence from bare JID was defined
>>> in 392x originally, so this could conceivably cause interop
>>> issues with older clients/servers.
>> 
>> notifications (from all full JIDs) before sending the
>> "unsubscribed" -- that seems preferable because the user is still
>> subscribed to the contact when the unavailable notifications are
>> sent, then the contact's server sends the "unsubscribed" as the
>> coup de grace. :)
> 
> is that the text doesn't say to send this presence only if the
> contact was actually subscribed to the user. I know sending
> unsubscribed suggests that there was indeed a subscription - but
> pre-approvals give a good example of how that might go wrong now. The
> client may think it has pre-approved a contact, and now wishes to
> remove the pre-approval. It does this by sending unsubscribed, but
> another client has already at the same moment done the same - this
> causes the server to route the unsubscribed and also send unavailable
> presence from the user's resources, despite the remote contact never
> having been subscribed in the first place.

You're right, that section was muddled. This is better:

###

3.2.2.  Server Processing of Outbound Subscription Cancellation

   Upon receiving the outbound subscription cancellation, the contact's
   server MUST proceed as follows.

   1.  If the user's bare JID is in the contact's roster with a state of
       "None", "None + Pending Out", or "To" and the 'approved' flag is
       set to "true" (thus signalling a subscription pre-approval as
       described under Section 3.4), the contact's server MUST remove
       the pre-approval and MUST NOT route or deliver the presence
       stanza of type "unsubscribed" to the user.

   2.  if the user's bare JID is in the contact's roster with a state of
       "None", "None + Pending Out", or "To", the contact's server
       SHOULD NOT route or deliver the presence stanza of type
       "unsubscribed" to the user and MUST NOT send presence
       notifications of type "unavailable" to the user as described
       below.

   3.  Otherwise, as shown in the following examples, the contact's
       server MUST route or deliver both presence notifications of type
       "unavailable" and presence stanzas of type "unsubscribed" to the
       user and MUST send a roster push to the contact.

   While the user is still subscribed to the contact's presence (i.e.,
   before the contact's server routes or delivers the presence stanza of
   type "unsubscribed" to the user), the contact's server MUST send a
   presence stanza of type "unavailable" from all of the contact's
   online resources to the user.

   CS: <presence from=[email-masked]/balcony'
                 id='i8bsg3h3'
                 type='unavailable'/>

   CS: <presence from=[email-masked]/chamber'
                 id='bvx2c9mk'
                 type='unavailable'/>

   Then the contact's server MUST route or deliver the presence stanza
   of type "unsubscribed" to the user, making sure to stamp the outbound
   subscription cancellation with the bare JID <contact@domain> of the
   contact.

   CS: <presence from=[email-masked]'
                 id='ij5b1v7g'
                 to=[email-masked]'
                 type='unsubscribed'/>

   The contact's server then MUST send a roster push with the updated
   roster item to all of the contact's interested resources, where the
   subscription state is now either "none" or "to" (see Appendix A).

   CS: <iq id='pw3f2v175b34'
           to=[email-masked]/balcony'
           type='set'>
         <query xmlns='jabber:iq:roster'>
           <item jid=[email-masked]'
                 subscription='none'/>
         </query>
       </iq>

   CS: <iq id='zu2y3f571v35'
           to=[email-masked]/chamber'
           type='set'>
         <query xmlns='jabber:iq:roster'>
           <item jid=[email-masked]'
                 subscription='none'/>
         </query>
       </iq>

###

> multiple possible actions. The server should observe the rules given
> in section 8.1 when choosing which action to take for a particular
> message.

+1, but I'll change "should" to "SHOULD" because I carefully scrubbed
all non-capitalized instances of the conformance keywords from the spec
at one point and I don't want any of those to creep back in. :)

>>>>> A.2.4: Question marks after "cancel pre-approval" -
>>>>> intentional? Cancelling pre-approvals is mentioned in the
>>>>> text in 3.2.1, though I think it would be helpful to mention
>>>>> it briefly in 3.4 also.
>>>> 
>>>> Implementation Note: A client can cancel a pre-approval by
>>>> sending a presence stanza of type "unsubscribed", as described
>>>> more fully under Section 3.2.  In this case the user's server
>>>> would send a roster push to all of the user's interested
>>>> resources with the 'approved' attribute removed.
>>>> 
>>> 
>>> Thanks, I missed that - looks good. The question marks in the
>>> table are not intentional though, are they?
>> 
>> They were intentional (to indicate that processing the
>> "unsubscribed" might result in cancelling the pre-approval), but
>> I've removed them because there is no state change in that case. So
>> now each of those cells in the table has:
>> 
>> |  no state change [1]  |
>> 
>> Where the footnote is:
>> 
>> I note in passing that we're kind of dancing around the question
>> of whether adding or removing a subscription pre-approval is a
>> state change (on par with something like "None+Pending-Out"), but
>> in the spec I'm saying that they are not subscription state
>> changes. That's my story and I'm sticking to it. :)
>> 
> 

I'm glad that someone is paying close attention. :) I felt a bit guilty
about that little dance, but I really didn't want to perform major
surgery on the spec by adding a bunch more subscription states (we've
got enough of those already!).

Peter

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

---

From: Matthew Wild <[email-masked]>
Date: Fri, 10 Sep 2010 17:06:29 +0100

>           <item jid=[email-masked]'

Much better, thanks. Though getting more picky... which rules are to
be followed if the user is not in the contact's roster at all? (or did
I miss some text that says the state is always assumed "None" then?).

> at one point and I don't want any of those to creep back in. :)

That's fine with me :)

Regards,
Matthew

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 10 Sep 2010 10:16:04 -0600

> I miss some text that says the state is always assumed "None" then?).

Heh, GMTA. I was thinking earlier that we need a blanket statement
somewhere that "not in the roster at all" falls under "None" for
processing purposes.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 10 Sep 2010 18:26:54 -0600

> somewhere that "not in the roster at all" falls under "None" for

To address this point, I've made some small tweaks to the text in
various sections.

I'm going to submit -13 now so that we can have a clear view of the
diffs resulting from this week's discussion.

Peter

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