Subject: Re: [xmpp] Alexey Melnikov's Yes on draft-ietf-xmpp-3921bis-18: (with COMMENT)

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 03 Jan 2011 09:54:56 -0700

[cc'ing [email-masked]]

On 1/2/11 12:35 PM, Alexey Melnikov wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-xmpp-3921bis-18: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> In 4.3.2:
> 
>       Implementation Note: The handling of the 'id' attribute in
>       relation to presence probes was unspecified in RFC 3921.  Although
>       the pattern of "send a probe and receive a reply" might seem like
>       a request-response protocol similar to the XMPP <iq/> stanza, in
>       fact it is not because the response to a probe might consist of
>       multiple presence stanzas (one for each available resource
>       currently active for the contact).  For this reason, if the
>       contact currently has available resources then the contact's
>       server SHOULD preserve the 'id' attribute of the contact's
>       original presence stanza (if any) when sending those presence
>       notifications to the probing entity; however,
> 
> Use of "however" can be read as if the 'id' attribute is not to be returned
> in the case specified below, however it is still returned. I suggest dropping
> "however" here.

I suggest:

s/however/by contrast/

>       if the contact
>       currently has no available resources, the probing entity is not
>       authorized (via presence subscription) to see the contact's
>       presence, or an error occurs in relation to the proble, then the
>       contact's server SHOULD mirror the 'id' of the user's presence
>       probe when replying to the probing entity.
> 
> In 4.5.2:
> 
>    The user's server MUST also send the unavailable notification to all
>    of the user's available resources (including the resource that
>    generated the presence notification in the first place).
> 
> Comment: The text in (): but the resource is unavailable :-).

The resource is unavailable for presence purposes, but still connected
to the server. I can see how "including" confuses the reader, though. I
suggest:

   (as well as to the resource that generated the unavailable presence
   in the first place)

>    The <subject/> element MUST NOT contain mixed content (as defined in
>    Section 3.2.2 of [XML]).
> 
> Should the same be said about presence' <status> element?

Yes, and also for the <show/> and <priority/> children of <presence/>.

> 11.  Security Considerations
> 
>    o  A user's server MUST NOT leak the user's network availability to
>       entities who are not authorized to know the user's presence,
>       either via an explicit subscription as described herein or via an
>       existing trust relationship (such as presence-enabled user
>       directories within organizations).
> 
> I don't understand this paragraph. If a user is subscribed to presence,
> then she is authorized to know user's presence?

I don't understand your lack of understanding. :) But perhaps this is
clearer:

   o  A user's server MUST NOT leak the user's network availability to
      entities who are not authorized to know the user's presence, where
      authorization typically takes the form of an explicit subscription
      from a contact to the user (as described under Section 3) but
      might take the form of an existing trust relationship (such as a
      presence-enabled employee directory within an organization that
      mandates the sharing of presence information as part of an
      employment agreement).

Peter

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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 03 Jan 2011 19:09:19 +0000

Hi Peter,

>>in the case specified below, however it is still returned. I suggest dropping
This still seem to imply that in the latter case something different 
happens to 'id'. But unless I am mistaken "SHOULD preserve the 'id'" and 
"SHOULD mirror the 'id'" mean the same thing.

>   (as well as to the resource that generated the unavailable presence
Ok.

>Yes, and also for the <show/> and <priority/> children of <presence/>.
Yes. But I think they are already covered.

>I don't understand your lack of understanding. :) But perhaps this is
Not really.

>      mandates the sharing of presence information as part of an
Can you split this into multiple sentences instead of one compound 
sentence? In particular, the part "where authorization typically takes 
the form of an explicit subscription from a contact to the user (as 
described under Section 3)" is confusing, because this is talking about 
proper authorization which (if my understanding is correct) doesn't 
actually leak presence.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 03 Jan 2011 12:26:47 -0700

> "SHOULD mirror the 'id'" mean the same thing.

In the first case, the server preserves the 'id' of the original
presence notification generated by the presentity. In the second case,
the server mirrors the 'id' of the presence probe it received from the
contact.

> Yes. But I think they are already covered.

In version -18 it's not explicitly called out that those child elements
mustn't contain mixed content. I've fixed that in my working copy.

> proper authorization which (if my understanding is correct) doesn't

True.

Here is another try:

   o  A user's server MUST NOT leak the user's network availability to
      entities who are not authorized to know the user's presence.  In
      XMPP itself, authorization takes the form of an explicit
      subscription from a contact to the user (as described under
      Section 3).  However, some XMPP deployments might consider an
      entity to be authorized if there is an existing trust relationship
      between the entity and the user who is generating presence
      information (as an example, a corporate deployment of XMPP might
      automatically add the user's presence information to a private
      directory of employees if the organization mandates the sharing of
      presence information as part of an employment agreement).

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 03 Jan 2011 19:30:08 +0000

>>>On 1/2/11 12:35 PM, Alexey Melnikov wrote:
 [...]

>      presence information as part of an employment agreement).
This is much better, thanks.