[Standards] [XEP-0277] Should we use the whole RFC when a XEP is based upon one
jonas at wielicki.name
Thu Jun 22 07:40:10 UTC 2017
On Mittwoch, 21. Juni 2017 22:07:48 CEST Goffi wrote:
> a practical question: XEP-0277 is based upon Atom (RFC 4287) but doesn't use
> the whole spec in the specified use cases. Movim use a <link rel="related">
> or <link rel="enclosure"> to attach images: XEP-0277 doesn't talk at all
> about that, but it is specified in RFC 4287.
> Do we consider that the whole RFC is usable for XEP-0277, or only use cases
> specified in XEP-0277? I'm asking because those links are not handled yet in
> SàT, and impleting the whole RFC to handle every possible use case is far
> more complicated than just XEP-0277, and XMPP overlap many use cases.
> Implementing the whole thing makes compatibility uncertain, in the present
> case an image was not shown in SàT because it's the first time I see a
> picture attached in a rel="enclosure" link, and XEP-0277 doesn't talk about
> it at all. But on the other hand, it allows many more thing than the XEP
> your opinion is really welcome on this question
I have to admit I have not looked deeply into the matters. XEP-0277 is still
experimental, that’s good.
I think that it makes sense to generally allow all of Atom to be used.
However, for common and ambiguous use-cases, it makes sense to add wording to
the XEP on how they SHOULD be handled preferrably when Atom is generated
within the XMPP network. I argue that SHOULD is right here (not MUST), to
allow interoperability, e.g. publishing a pre-existing RSS feed into the XMPP
Of course care should be taken that the suggested usage is compatible with
Atom, so that pre-existing Web-based entitise can read Atom feeds from XMPP
That’s just my two cents from someone not deeply into the matters.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards