goffisingpolyma's solution for disco feature attachment is far better than my proposal. I plan to update my proposal if it's fine with council members which have already voter in favor of it.
goffi(not now cause I'm at work)
flowgoffi, do you have a link to singpolyma's solution?
goffiflow: last email on standard@
flowha, was in my spam folder :/
goffiit's using disco extensions, and that is already included in caps, so I don't see any downside
goffiI'll reply later on standard@, I'm at work and will be in meeting soon.
KevI’m not 100% convinced it *is* a better solution.
flowKev, feel free to share why :)
goffiKev: why? Could you elaborate (maybe on standard@ would be better)
flowgoffi, same goes for you: why do you think this solution than your proposed one?
goffiI'll share on standard@, I'm in a meeting now.
goffiprobably write something tonight, after work.
flowI am myself torn between those two, as they both have their ups and downs
KevI might be completely misunderstanding the problem domain, but these are basically just traditional Disco features as far as I can see, and I’m not sure why the existing mechanism of just checking for the presence of a feature in the list doesn’t work here. Whereas the new proposal involves all consumers having to then do two-level map lookups for no benefit that is immediately obvious to me (although I might be missing it).
flownothing a good API can't hide from the user
KevIt seems to me that a consumer wants to know “Can I RSM with Disco” and that the normal approach of looking up the “RSM with Disco” feature works fine, and having to do “First I’ll lookup RSM, and if that’s present I’ll look up the RSM map in the attachments data form and see if that contains Disco” isn’t providing anything but additional complexity.
KevAlthough as a whole, I’m not entirely convinced this is a standards track XEP, rather than just a suggestion for how other XEPs could do their naming for optional features.
jonas’I share singpolymas concern about the opaqueness of the strings though
KevAh, but these *are* opaque strings.
KevYou’re not constructing these things arbitrarily.
KevIf ‘pubsub and rsm’ is a valid combination of things, that’s going to be defined in pubsub, rsm, or a pubsub+rsm spec that will be defining the feature.
jonas’if they were still opaque, we wouldn't need a XEP to write down how to construct the product of RSM + Disco
KevWhich is why I think this should really be little more than a suggestion of how you can name such a feature when you define it.
jonas’then it'd be informational I guess
KevAnd that is unecessary, because they’re opaque.
KevYes, I agree with that ‘we wouldn’t need’ - I don’t think this is really needed.
jonas’unless people really care about the genericity, in which case singpolyma's approach is saner in the sense that it doesn't violate the opacity
KevIt feels to me like this is an rsm-specific sticky plaster over rsm being MTI for some specs, but not widely deployed and wanting to advertise after-the-fact who advertises it. But for that, it’d be better to be explicit in the source XEPs.
jonas’well, RSM is not MTI for '30
jonas’and there's no way to retrofit a feature for RSM into '30
jonas’you could add it to RSM itself, sure
emusother topic: Any member working at Isode to review and confirm: https://github.com/xsf/xmpp.org/pull/885
flowemus: you mean #950, right?
Kevjonas’: right, for disco it’d be in RSM, or in RSM+Disco.
KevI think this is really just a somewhat-bug in 59 that it says ‘just advertise rsm’, and fixing that to say “Individual protocols need to advertise RSM support themselves, unless MTI."
flowI am not sure why the discussion about "feature attachments" seems to only revolves around RSM, we have that problem in a few other areas too, notably E2EE✎
flowI am not sure why the discussion about "feature attachments" seems to only revolve around RSM now, we have that problem in a few other areas too, notably E2EE ✏
KevWhat’s the equivalent need in E2EE, flow?
flowexample: if you announce support for omemo, does that mean that you can also process encrypted chatstates
jonas’flow, that would be handled by SCE, not?
flowjonas’, I don't think so, no
flowunless you want to imply that implementing omemo means implementing a lot of other additinal protocols
jonas’OMEMO does not specify encrypted chat states at all.
flowand even then: what about future extensions?
jonas’only encrypted body.
jonas’so I don't see how a mere OMEMO feature would be related to encrypting non-body content at all.
jonas’for anything beyond that, there's stanza content encryption, and that has its own feature, I guess.
flowI am not sure if you are guessing right
flowdue the modularity of XMPP, at the point where you can combine one protocol with another, e.g. MAM+PubSub, or OMEMO+ChatStates, you need a way to announce those as distinct features
goffiKev: flow: you are right with the added complexity, I just find singpolyma cleaner, easier to read, and taking profite of XML. I don't think this can be informal though, as we need to know if the dfa is implemented to know if a missing 'http://jabber.org/protocol/rsm@http://jabber.org/protocol/pubsub' means that the RSM is not implemented for pubsub, or just that dfa is not implemented.
goffialso it's useful for other XEPs, order-by for instance.
goffiOk my meeting is resuming.
KevI didn’t say informal, I said it needs to be specified in the respective XEPs.
MattJI'm inclined to agree
MattJOtherwise you could advertise interesting combinations of features without it being clearly specified what that means
MattJIf you say you support RSM for MUC, how does that function exactly?
MattJ313 has semantics around the use of RSM, such as saying the RSM IDs match the archive IDs
MattJAnd I think this will apply to most things
Kev313 also has (or rather, used to have and is split off) semantics around 313 with 60.
KevYou also couldn’t just advertise omemo+csn and expect it to work usefully without arbitrary element OMEMO being defined.
MattJSo I agree that either RSM support is declared mandatory by the source XEP (if you advertise MAM support, you *must* support RSM), or you need to document it somewhere else if it's optional
KevOr not somewhere else, even if it’s optional.
KevWhich I *think* is what you meant.
MattJYou can't just combine arbitrary features and expect everyone to understand what that means
jonas’all very reasonable
MattJEr, sure, it can be optional in a protocol indeed
goffisure nothing prevent to explain it directly in concerned XEPs, I did it in last version of https://xmpp.org/extensions/xep-0413.html#disco . But that means that you have to repeat each time how to produce the disco feature string, instead of just linking to a XEP, and also that we have to update all concerned XEPs, and for some of them we can't bump version, so how do we know if the feature is implemented or not? With dfa, you can just say "this feature can be attached as of XEP-xxx (dfa)", and if necessary explain what that means.
jonas’there is no way to produce an opaque string
flowI think everyone aggrees that the combination of two protocol extensions need to be declared and specified somewhere (even if it is trivial)✎
flowI think everyone agrees that the combination of two protocol extensions need to be declared and specified somewhere (even if it is trivial) ✏
Kev> there is no way to produce an opaque string