Re: SIMS and SFS, was: Re: Proposed XMPP Extension: Emoji Markup

>Are we reading the same words? Let me quote the introduction of XEP-
>0446 for you.
>
>> This resulted in the situation that XEPs like Stateless
>> Inline Media Sharing (XEP-0385) [2] depend on the mostly unrelated
>> Jingle (XEP-0166) [3] just for the metadata element. The motiviation
>> of this XEP is to get rid of such dependencies and have a dedicated
>> place to define a file metadata element.

This is the quote right here. Says it doesn't like what was done in SIMS and 
so this XEP exists to change that.

>> Since this is most of the purpose of using sims or sfs (to get the
>> hash) it seems reasonable?
>
>I didn't know that was the main purpose of SIMS or SFS. Also surprises
>me, given that some implementation neither send nor process the hash.
>I'm pretty sure the main reason so far for people to implement SIMS or
>SFS is to get thumbnails.

I didn't know anyone was really doing thumbnails but sure that's another 
very visible use if so.

>> I think I've been pretty clear oves the years that my main objection
>> is the use of xep0446.
>
>I get that now. Though it makes me wonder why you prefer the <file/>
>from Jingle File Transfer that puts restrictions and rules in place
>that are not required for the generic case of file metadata and also
>means everyone has to suddenly implement Jingle File Transfer only
>because they want to do file metadata?

No one has to implement Jingle File Transfer if all they want is to parse 
this metadata element. The implementat the metadata element. If they happen 
to implement Jingle FT they can possibly share some code for both cases but 
certainly they don't need any of the rest of Jingle for SIMS use.

Are there odher restrictions of concern than hash? Jingle requires hash 
because it was considered essential to the generic case of transferring a 
file, but if we no longer consider that essential I expect we want to remove 
this requirement from Jingle as well.

>> Sure, for example https://datatracker.ietf.org/doc/html/rfc5854 also
>> defines an equivalent element.
>
>that we likely won't use. With the overlap being essentially file name,
>file size and description, it feels weird to pull in a dependency on a

Name, size, description, mime, and hash are basically everything we have in 
jingle and in sfs and are also in metalink. I understand that at this point 
in history maybe there are reasons not to use metalink (we could have used 
their hash element everywhere but already have our own in so many XEPs by 
now that ship has sailed, for example, and so would be a bit odd).

-- 
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]