[Standards] [XEP-0277] Should we use the whole RFC when a XEP is based upon one

Jonas Wielicki jonas at wielicki.name
Thu Jun 22 07:40:10 UTC 2017

On Mittwoch, 21. Juni 2017 22:07:48 CEST Goffi wrote:
> Hi,
> 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
> alone.
> 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.

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170622/be1cb767/attachment-0001.sig>

More information about the Standards mailing list