[Standards] XEP-0359 Client vs. non-client IDs

Guus der Kinderen guus.der.kinderen at gmail.com
Fri Sep 30 06:42:50 UTC 2016


I agree with Kev. If an entity does not wish to expose its address, it can
simply choose to not provide the 'by' attribute. There's need to explicitly
define the client/server role in that action too, right?

 - Guus

On 29 September 2016 at 20:18, Kevin Smith <kevin.smith at isode.com> wrote:

> On 29 Sep 2016, at 19:08, Florian Schmaus <flo at geekplace.eu> wrote:
> >
> > On 29.09.2016 19:22, Guus der Kinderen wrote:
> >> Hi,
> >>
> >> What's the purpose of the distinction between "Unique Stanza IDs" and
> >> "Client generated stanza IDs"? Why not add a unbounded list of stanza-id
> >> elements (each with a unique 'by' attribute value), and not worry about
> >> what entity is serving in a client-capacity?
> >
> > It was designed that way to avoid leaking the client's XMPP address in
> > cases like MUC. Notice that <stanza-id/> has a 'by' attribute whereas
> > <client-id/> has not. I should add that rationale to the XEP.
>
> That makes sense, but why not just say something like “the stanza-id
> without a by is the originating entity”. Else sometimes the orginating
> entity stamps with a client-id (when it’s a client) or doesn’t (when it’s a
> server), or you have servers stamping with client-id, or whatever.
>
> /K
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160930/e57ec0d5/attachment.html>


More information about the Standards mailing list