Re: [Standards] Council Minutes 2020-10-21

[Georg Lukas]

* Tedd Sterr  [2020-10-23 15:35]:
> 4a) MR !22 (XEP-0118: add composer, date, genre, language, lyricist, and 
> performer tags; make rating optional) - 
> https://gitlab.com/xsf/xeps/-/merge_requests/25

I'd also like to see some more exploration of what's possible in this
space (put the tune in BoB? Add an OOB URL element?), but won't block
this PR based on that.

As there is prior art of changing this XEP, and nobody has ever
complained about `rating` being mandatory, I can also be bold here.

+1!


Georg


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

Re: [Standards] Council Minutes 2020-10-21

[Florian Schmaus]

On 10/23/20 3:31 PM, Tedd Sterr wrote:

*4a) MR !22 (XEP-0118: add composer, date, genre, language, lyricist, 
and performer tags; make rating optional)* - 
https://gitlab.com/xsf/xeps/-/merge_requests/25 

Zash notes that XEP-0118 is Draft and the namespace is non-versioned. 
Jonas wonders about adding the new details in a separate namespace under 
the same child.
Dave feels that an entirely new User Tune 2 (Empire Records Strikes 
Back), assuming there's prior art now, thanks to popular music streaming 
services, which is worth exploring - Daniel probably agrees.
Jonas doesn't think there is harm, from a practical perspective, in 
adding elements scoped into a different namespace - Zash doesn't think 
there's much harm in just accepting this, unless someone has a strict 
validator; notes that the last modification was the addition of the 
rating element (in Draft, without an additional namespace.)


Jonas: +1
Zash: +1
Dave: -0
Georg: [on-list]
Daniel: -0

Kev notes that strict schema validators are sometimes used to ensure 
content conforms, and so feels this falls far short of avoiding 
backwards-incompatible modifications if at all possible - Jonas agrees.


MR !22 only adds new *non-mandatory* elements. Hence this is a backwards 
compatible change: Old implementations do to not expect those elements, 
and will simply ignore unknown data, assuming that this data is not 
strictly required for the protocol's functionality. Which is true here. 
As result, senders send the new metadata opportunistically. The more the 
recipient understands of this metadata, the better. But there is no need 
in negotiating this [1]. So even in the presence of validators, this 
does not require a namespace bump.


Only if new *mandatory* elements or attributes are added, a namespace 
bump is required. Because then, a strictly validating entity, following 
the new specification, will abort in case those are missing.


In the past we added new optional elements to existing namespaces [2]. 
As Zash notes, XEP-0118 is an example for this. I do not see why this 
should change, nor do I want this to change. Adding new *optional* 
elements under a new namespace complicates implementations for no gain.


- Florian


1: We could consider adding a disco#info feature flag, signalling that 
the new elements are understood. I don't see a need for that, on the 
other hand, I probably won't hurt. And this is unrelated to the "is a 
new namespace required for new optional elements?" question.


2: Of course, there have been exceptions of this. XEP-0440 comes to 
mind. But here, the reason for a new namespace was that we did not own 
the original namespace. And this is not true here (i.e. for XEP-0118).







OpenPGP_0x8CAC2A9678548E35.asc
Description: application/pgp-keys


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