On 02.06.2017 12:57, Daniel Gultsch wrote:
> 2017-06-01 13:12 GMT+02:00 Kevin Smith <[email protected]>:
>> On 1 Jun 2017, at 11:22, Daniel Gultsch <[email protected]> wrote:
>>> I went ahead an created a PR for XEP-0384 to match what is actually
>>> implemented in the wild.
>>> ...
>>> I changed the track from Standards to Historical.
>>> I checked: Track changes have happened before and are apparently
>>> possible if Council agrees.
>>> I think this is the best way forward given that developers and users
>>> who are *currently* looking for the OMEMO spec are probably looking
>>> for this XEP and not OMEMO-NEXT.
>>> Also we don't have to assign a new author as it would be the case if
>>> XEP-0384 would become OMEMO-NEXT.
>>
>> I think that, while someone interested in implementing OMEMO-SIACS might 
>> find it convenient for 384 to be changed in this way, what the XSF wants is 
>> to push people towards Standards Track XEPs and in this case, 384 seems to 
>> be the logical place.
>>
>> Conceptually, changing 384 to historical and changing the content is very odd
> 
> If it is easier 'conceptually' I'm also fine with leaving it in the
> Standards track and marking it as deprecated.
> 
> The point is that OMEMO in its current form is extremely popular. How
> many XEPs have Wikipedia and online news media (LWN, Golem) articles
> written about them?
> If the current consensuses is to take OMEMO in a different direction
> with OMEMO-NEXT that's fine. But don't water down the current state by
> sending it to the attic.
> The state of OMEMO as described in my PR is what people will use for
> the foreseeable future. If the XSF wants to push people in a different
> direction (OMEMO-NEXT) they can do this by deprecating XEP-384 (and
> create a link to OMEMO-NEXT)

+1

Having XEP-0384 describe what is currently implemented is sensible.

- Florian


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________

Reply via email to