[Standards] RFC 6121, Sec 3.1, 3.2, and 4.3.2

Dave Richards drichards at coversant.com
Tue Nov 15 18:22:54 UTC 2011


Am I missing something or is there a bit of a hole in these sections
regarding denying a subscription?

In 3.1.2 (subscription request outbound), the user's server pushes a roster
entry containing "the potential contact with a subscription state of "none"
and with notation that the subscription is pending".

In 3.2.3 (subscription cancellation inbound), the user's server is supposed
to ignore the subscription cancellation unless "the contact is in the
user's roster with subscription='to' or subscription='both'"  And a few
lines later:  "Otherwise ... if the contact is in the user's roster with a
subscription state other than those described in the foregoing check --
then the user's server MUST silently ignore the unsubscribed notification
by not delivering it to the user, not modifying the user's roster, and not
generating a roster push to the user's interested resources".

Seems like a subscription denial/rejection would never get processed on the
user side.

3.1.6 (subscription approval inbound) talks about subscription none/from
with pending out, which seems should also be considered in 3.2.3.


In an unrelated issue, 4.3.2, #1 says to send "unsubscribed" if "the
contact account does not exist or the user's bare JID is in the contact's
roster with a subscription state other than "From", "From + Pending Out",
or "Both"".  Seems like this should also be the case if the contact account
exists but is not in the user's roster at all.  All other roster states are
covered by available/unavailable, so it seems lack of a response would
indicate that the account at least exists, which might be considered
leaking information, as well as leaving the user with apparently a dead
"to" subscription to the contact.


After a brief look I did not find any previous discussion of these, so if
there is can someone please point me there?  If not, what do you think?


Thanks,

Dave Richards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20111115/c38b3a6b/attachment.html>


More information about the Standards mailing list