On 4/20/20 3:08 PM, Matthew Wild wrote: > On Fri, 17 Apr 2020 at 12:58, Florian Schmaus <[email protected] > <mailto:[email protected]>> wrote: > > On 4/16/20 3:02 PM, Florian Schmaus wrote: > > On 4/3/20 10:51 PM, Matthew Wild wrote:> The PRs are here: > >> > >> XEP-0313: https://github.com/xsf/xeps/pull/922 > >> > >> Feedback very welcome, but I hope we can get this wrapped up and > >> advanced to Draft where it should be soon! > > > > I have two further minor remarks: > > > > I wondered if "fetching a single message" shouldn't be "fetching > > messages by a list of archive IDs", where single message fetching is > > just using a list of size one. If we ever specify "fetch-by-id-list", > > then we would end up with two ways to retrieve a single message by id, > > which feels odd to me. > > The more I think about it the more I come to the conclusion that we > should simply specify (and register) a well known field for message IDs > with type list-multi, instead of doing the proposed single message > fetching. > > > Interesting issue I just realised. I'm not sure list-multi is > necessarily a good fit semantically. XEP-0004 says this: > >> A form-submitting entity chooses one or more items from among the > options presented by the form-processing entity and MUST NOT insert new > options. > > An alternative is text-multi which does allow arbitrary values, but is > defined to be multiline. At least Prosody is going to merge this into a > multiline string before the MAM code would see it (and would have to > parse it back into individual values).
Not considering implementation specific internals: Would text-multi be be a good fit? - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
