[Standards] Pending XEP changes

[Florian Schmaus]

Folks,

https://github.com/xsf/xeps/pull/496

is in limbo for over half a year. What can I as contributor do to get it
processed (rejected, applied, applied with changes)?

- 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] Message-IDs

[Florian Schmaus]

On 13.02.2018 21:42, Simon Friedberger wrote:
> On 13.02.2018 17:57, Simon Friedberger wrote:
>>>     C2. According to Daniel it is not clear which ID should be used when
>>>     referencing things. In other words if he gets a delivery receipt
>>> for an
>>>     ID the client might have based that on the origin-ID or the
>>> message-ID.
>> Delivery receipts predate xep359 so it is safe to say that the intention
>> is that delivery receipts use rfc6120-ids. While it is IMHO obvious from
>> reading xep184 that it is based on rfc6120-ids, it can't hurt to specify
>> this more explicitly.
> But looking at https://xmpp.org/extensions/xep-0045.html#message
> the message-ID seems to be rewritten to different values for different
> recipients.
> How can a client who gets a delivery receipt with such an ID figure out
> which
> message it is for?

You can not reliable figure it out with the current specifications. One
possibly option is to extend xep184 receipts to (optionally) include
xep359 IDs. Maybe that would even be a backwards compatible change, e.g.
clients could check for the xep359 ID in the receipt and fall back to
the rfc6120 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] Entity Capabilities 2.0

[Christian Schudt]

Hi Jonas,


> You are referring to the processing entities side? The entity is free to 
> choose from the set as it desires. The order of elements inside the hash set 
> is undefined. It could for example iterate a list of hash functions in 
> descending order of preference and look for hashes in the hash set. It could 
> also first check if any of the hashes is in the cache and prefer that.
> 
> I see this could be clarified, but I’m hesitant to make a normative statement 
> on the behaviour. Some suggestions can be put into the XEP though. Do you see 
> a reason to make this normative?
> 

See, you made a good point here: First check if any of the hashes is in the 
cache.
I forgot about it in my implementation and that’s why I think it could be 
beneficial to have something defined in the specification.

Think about the same capabilities sent by two different entities, but with a 
different hash order each.

abc
def



def
abc


If an implementation would just pick the first hash each time it processes a 
presence with Caps, it will likely end up with two service discovery requests 
and two hashes in the cache, although one would be enough.

The spec should recommend to first iterate over all hashes and check for each 
hash, if it’s already known (cached).

> I *think* I outlined the integration with XEP-0115 in the XEP already. Can 
> you 
> be more specific on where you would like guidance?

You write (or I understand): If there are also `115 Caps, you may use them to 
get the disco#info from the cache.
In the next sentence: you must not use data from the 115 cache, if there are 
also 390 Caps in the presence.
*confusing*?

Generally I thought about some guidance about what I’ve worked out during my 
implementation: Some ideas about a common interface and some business rules for 
processing both Caps Extensions in the same presence.
In the same sense how XEP0191 describes the relation to XEP0016 and recommends 
to use the same backend storage and defines a clear mapping [1].

Maybe also some words about if XEP0115 cache can be mixed with XEP0390 cache.
In my implementation I use the same cache for both.
Maybe you also have some recommendations what to use as cache keys.
In my implementation I currently use something like: „sha1(XEP# + algo + 
bas64(hash)). Not sure if it’s good.

[1]: https://xmpp.org/extensions/xep-0191.html#privacy


> Any element in XML can have an xml:lang attribute. It is specified in the XML 
> standard on how the value of xml:lang propagates.
> 
> Yes, at it propagates down the tree, unless another element (e.g. the 
> presence) overrides it. For example:
> 
> 
>  […]
>  
>
>  
>
>  
>  […]
> 
> 
> In this case, the identity element would be assumed to have the language 
> "en". 
> If the xml:lang on the query was missing, it would be "de" and so on.
> 

Oh wow, understood. Let’s see what will happen about the language...

— Christian

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

Re: [Standards] Council Agenda 2018-02-14

[Kevin Smith]

On 13 Feb 2018, at 17:28, Dave Cridland  wrote:
> 
> On 13 February 2018 at 17:20, Evgeny Khramtsov  wrote:
>> Tue, 13 Feb 2018 17:04:36 +
>> Dave Cridland  wrote:
>> 
>>> 4) Deprecate XEP-0013 Flexible Offline Message Retrieval
>>> 
>>> https://xmpp.org/extensions/xep-0013.html
>> 
>> Just my 3 cents: this XEP is, from what I know, the only way to disable
>> offline messages on a client, so we need a similar mechanism if the XEP
>> is going to be deprecated.
> 
> Yes, good point.
> 
> On a more general note, the process around deprecation is pretty weak
> - it might be useful to formally gather feedback about deprecating a
> spec in the same way we gather it for advancement.
> 
> Currently, anyone can ask the Council to vote, and the Council can
> simply do so. That's not really very helpful, and in practise we do
> try to solicit opinion from across the community.
> 
> As such, I'm thinking of writing something for XEP-0001 that imposes a
> last-call-like period for comments - Intent To Deprecate/Obsolete
> perhaps - and imposing that on ourselves.

It’s not immediately clear to me that this is truly needed. The process as-is 
seems sufficiently tight (‘Council votes’) that it’s not causing issues right 
now, and I’m not sure that adding a mandatory almost-LC would address possible 
future problems (although I think Council getting a feeling of the land before 
voting is sensible).

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

Re: [Standards] Message-IDs

[Simon Friedberger]

Hi Florian,
thanks for chiming in!

On 13.02.2018 17:57, Simon Friedberger wrote:
>>     C2. According to Daniel it is not clear which ID should be used when
>>     referencing things. In other words if he gets a delivery receipt
>> for an
>>     ID the client might have based that on the origin-ID or the
>> message-ID.
> Delivery receipts predate xep359 so it is safe to say that the intention
> is that delivery receipts use rfc6120-ids. While it is IMHO obvious from
> reading xep184 that it is based on rfc6120-ids, it can't hurt to specify
> this more explicitly.
But looking at https://xmpp.org/extensions/xep-0045.html#message
the message-ID seems to be rewritten to different values for different
recipients.
How can a client who gets a delivery receipt with such an ID figure out
which
message it is for?

>> E) Suggested solutions, including partial solutions:
>>     E1. message-ID and origin-ID should always be the same,
>>     According to Daniel and Georg things currently break down anyway
>> if this does not hold.
> I don't now why things should break down if this does not hold.
I think because it is difficult to match IDs to messages due to the reasons
mentioned above.

>>     C3. Using origin-ID to detect MUC reflection doesn't always work
>> because MUCs
>>     may not reflect it.
> A short note: If a MUC service announces support for 'urn:xmpp:sid:0'
> then the service is required to reflect the xep359 IDs. So clients are
> at least able to determine if the MUC will reflect the xep359 extension
> elements (but not if the MUC won't).
And client developers should probably refuse to join MUCs that don't.
Mandating it in the standard might still be good motivation for transport
implementers.

>>     C5. Some MUCs rewrite the message-id
>>     Why is this allowed? It is even suggested here:
>>     https://xmpp.org/extensions/xep-0045.html#message
> Hehe, that's an old discussion. Some people argue that the reflected
> message is not the initial message and thus, could get a new ID. I also
> think that the MUC way wants to enforce unique IDs for reflected
> messages, which may not be guaranteed if the MUC service would need to
> use the client provided ID.
>
> No matter what, I doubt that this will change in the future. Although I
> have currently a neutral stance, XEP-0045 is to some degree set in
> stone, it it unlikely to get such a fundamental change.
This is an interesting point. I overlooked that it is exacerbated by
the fact that some MUCs split messages so an ID for some messages is
simply not available.
Hm...
What is the correct behavior here?
Clearly, having messages with the same ID does not work for referencing,
corrections, whatever..
On the other hand if a new ID is generated the client needs to be told
that the server just made it say something and it can now expect delivery
receipts for that.

When hashing the message this is forced. It will change the ID
and the client has to know.

I don't see how this can be solved without a "bounce" since the bounce isn't
one because the server generated the message.


>> ...
> Sounds like an interesting approach which we should explore.
But apparently it doesn't work. xD


>> ...
> You are mixing multiple problems with multiple solutions, which was
> probably in an effort to get the whole picture, but also leads to
> confusion. I personally would like to concentrate on solving C4, where
> you pointed out a promising candidate for a solution: E2
Indeed. Mostly because I still don't think that I understand the
complete picture.
For example, if we are only trying to solve C4, is that really worth the
effort?
Does it do anything more than save a round-trip?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Agenda 2018-02-14

[Peter Saint-Andre]

On 2/13/18 11:55 AM, Sam Whited wrote:
> On Tue, Feb 13, 2018, at 11:28, Dave Cridland wrote:
>> Currently, anyone can ask the Council to vote, and the Council can
>> simply do so. That's not really very helpful, and in practise we do
>> try to solicit opinion from across the community.
>>
>> As such, I'm thinking of writing something for XEP-0001 that imposes a
>> last-call-like period for comments - Intent To Deprecate/Obsolete
>> perhaps - and imposing that on ourselves.
> 
> Please don't. We already have too much process making it impossible for us to 
> get anything done in a reasonable time frame. I don't see what problem this 
> is solving so I don't see the need for more process to solve something that 
> hasn't (to my knowledge) caused any problems.

But Dave enjoys imposing process on himself!

Peter




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

Re: [Standards] Council Agenda 2018-02-14

[Sam Whited]

On Tue, Feb 13, 2018, at 11:28, Dave Cridland wrote:
> Currently, anyone can ask the Council to vote, and the Council can
> simply do so. That's not really very helpful, and in practise we do
> try to solicit opinion from across the community.
> 
> As such, I'm thinking of writing something for XEP-0001 that imposes a
> last-call-like period for comments - Intent To Deprecate/Obsolete
> perhaps - and imposing that on ourselves.

Please don't. We already have too much process making it impossible for us to 
get anything done in a reasonable time frame. I don't see what problem this is 
solving so I don't see the need for more process to solve something that hasn't 
(to my knowledge) caused any problems.

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

Re: [Standards] Council Agenda 2018-02-14

[Goffi]

Le mardi 13 février 2018, 18:28:02 CET Dave Cridland a écrit :

> As such, I'm thinking of writing something for XEP-0001 that imposes a
> last-call-like period for comments - Intent To Deprecate/Obsolete
> perhaps - and imposing that on ourselves.

That's a really good idea! 
 
> Dave.


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

Re: [Standards] Council Agenda 2018-02-14

[Dave Cridland]

On 13 February 2018 at 17:20, Evgeny Khramtsov  wrote:
> Tue, 13 Feb 2018 17:04:36 +
> Dave Cridland  wrote:
>
>> 4) Deprecate XEP-0013 Flexible Offline Message Retrieval
>>
>> https://xmpp.org/extensions/xep-0013.html
>
> Just my 3 cents: this XEP is, from what I know, the only way to disable
> offline messages on a client, so we need a similar mechanism if the XEP
> is going to be deprecated.

Yes, good point.

On a more general note, the process around deprecation is pretty weak
- it might be useful to formally gather feedback about deprecating a
spec in the same way we gather it for advancement.

Currently, anyone can ask the Council to vote, and the Council can
simply do so. That's not really very helpful, and in practise we do
try to solicit opinion from across the community.

As such, I'm thinking of writing something for XEP-0001 that imposes a
last-call-like period for comments - Intent To Deprecate/Obsolete
perhaps - and imposing that on ourselves.

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

Re: [Standards] Council Agenda 2018-02-14

[Evgeny Khramtsov]

Tue, 13 Feb 2018 17:04:36 +
Dave Cridland  wrote:

> 4) Deprecate XEP-0013 Flexible Offline Message Retrieval
> 
> https://xmpp.org/extensions/xep-0013.html

Just my 3 cents: this XEP is, from what I know, the only way to disable
offline messages on a client, so we need a similar mechanism if the XEP
is going to be deprecated.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___