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

[Peter Saint-Andre <[e-mail]>]

[cc'ing [e-mail]]

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/