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
___

[Standards] Council Minutes 2020-10-21

[Tedd Sterr]

https://logs.xmpp.org/council/2020-10-21?p=h#2020-10-21-b57e703886bf4bfe

1) Roll Call
Present: Zash, Dave, Jonas, Daniel, Georg

2) Agenda Bashing
No.

3) Editor's Update
* Accepted XEP-0352 (Client State Indication) as Draft
* Accepted XEP-0411 (Bookmarks Conversion) as Draft

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.

4b) Propose Martin Dosch as Editor
Jonas: +1
Georg: +1
Daniel: +1
Zash: +1
Dave: +1

Dave doesn't think he's had much contact with them, but anyone willing to put 
in the work sounds like a good idea - Jonas notes this is 'mdosch' (the artist 
formerly known as !XSF_Martin).

5) Date of Next
2020-10-28 1600 UTC

Jonas may not be able to chair.

[Note: DST ends in Europe on the 25th, so the meeting is effectively one hour 
later for those outside of affected regions; the USA catches up the week after.]

6) AOB
Jonas notes the Elections [1] - the deadline for applications is 2020-11-08 - 
please add your application and/or encourage others you think would be good in 
any of these roles.

7) Close
Thanks everyone.

Jonas reminds Dave that he wanted to start a thread on OOB/SIMS/etc in the 
context of the XEP-0363 CFE - Dave was fully intending to do that (and has [2].)

Zash quotes from XEP-0001: "Any changes to a Draft XEP that could reasonably be 
construed as material must be provisionally published, announced and discussed 
on the Standards mailing list, and formally approved by the XMPP Council" - 
Dave is a lot more comfortable when changes are thoroughly discussed within the 
community. (See [3] for conveniently relevant discussion.)


[1] https://wiki.xmpp.org/web/Board_and_Council_Elections_2020
[2] https://mail.jabber.org/pipermail/standards/2020-October/037822.html
[3] https://logs.xmpp.org/xsf/2020-09-12?p=h#2020-09-12-7b989cb42bd803af

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