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

[Guus der Kinderen]

I appreciate the implementation-related argument too. I don't think that
that argument should outweigh the value of applying clear, concise
naming. Removing the "client/server" role is a big improvement there.
There's no use-case for this XEP where the 'by' is left out by an entity
that's not an 'origin' entity?

On 3 October 2016 at 11:11, Kevin Smith  wrote:

>
> > On 2 Oct 2016, at 18:46, Florian Schmaus  wrote:
> >
> > On 29.09.2016 20:18, Kevin Smith wrote:
> >> On 29 Sep 2016, at 19:08, Florian Schmaus  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  has a 'by' attribute whereas
> >>>  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”.
> >
> > That's the other approach I could have taken when designing the protocol
> > (and I find myself often in the situation where I have to decide between
> > those two approaches when working on new extension protocols for XMPP).
> >
> > I personally find the variance it introduces, that the 'by' attribute
> > can either exit or not, less desirable. Instead I enjoy the fact that I
> > can look at the element's name and tell if it requires a non-empty 'by'
> > attribute or that it must not have one. I find this preferable when
> > writing parsers, designing classes for extension elements (e.g. a method
> > "getBy()" will always return a JID for the class 
> > represents), or writing the XEP itself.
>
> I can buy that argument.
>
> >
> >> 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.
> >
> > Fair point. How about 's/client-id/origin-id/‘?
>
> Or just origin? Either way, I think an improvement, yes.
>
> /K
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Kevin Smith]

> On 2 Oct 2016, at 18:46, Florian Schmaus  wrote:
> 
> On 29.09.2016 20:18, Kevin Smith wrote:
>> On 29 Sep 2016, at 19:08, Florian Schmaus  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  has a 'by' attribute whereas
>>>  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”.
> 
> That's the other approach I could have taken when designing the protocol
> (and I find myself often in the situation where I have to decide between
> those two approaches when working on new extension protocols for XMPP).
> 
> I personally find the variance it introduces, that the 'by' attribute
> can either exit or not, less desirable. Instead I enjoy the fact that I
> can look at the element's name and tell if it requires a non-empty 'by'
> attribute or that it must not have one. I find this preferable when
> writing parsers, designing classes for extension elements (e.g. a method
> "getBy()" will always return a JID for the class 
> represents), or writing the XEP itself.

I can buy that argument.

> 
>> 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.
> 
> Fair point. How about 's/client-id/origin-id/‘?

Or just origin? Either way, I think an improvement, yes.

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Florian Schmaus]

On 29.09.2016 20:18, Kevin Smith wrote:
> On 29 Sep 2016, at 19:08, Florian Schmaus  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  has a 'by' attribute whereas
>>  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”.

That's the other approach I could have taken when designing the protocol
(and I find myself often in the situation where I have to decide between
those two approaches when working on new extension protocols for XMPP).

I personally find the variance it introduces, that the 'by' attribute
can either exit or not, less desirable. Instead I enjoy the fact that I
can look at the element's name and tell if it requires a non-empty 'by'
attribute or that it must not have one. I find this preferable when
writing parsers, designing classes for extension elements (e.g. a method
"getBy()" will always return a JID for the class 
represents), or writing the XEP itself.

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

Fair point. How about 's/client-id/origin-id/'?

- Florian








signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Guus der Kinderen]

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  wrote:

> On 29 Sep 2016, at 19:08, Florian Schmaus  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  has a 'by' attribute whereas
> >  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-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Kevin Smith]

On 29 Sep 2016, at 19:08, Florian Schmaus  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  has a 'by' attribute whereas
>  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-unsubscr...@xmpp.org
___

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

[Florian Schmaus]

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  has a 'by' attribute whereas
 has not. I should add that rationale to the XEP.

- Florian




signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Kevin Smith]

On 29 Sep 2016, at 18:22, Guus der Kinderen  wrote:
> 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?

+1

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Guus der Kinderen]

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?

Regards,

  Guus
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___