XSF Discussion - 2020-09-10

I missed a board meeting, but so did everyone else?

Apparently

Ha, yes, seems so

Any pressing matters?

no - and I'm actually quite busy with work

None from me

I alt-tabbed through me calendar by accident 🙂

My phone notified me 10 minutes before the meeting, but 10 minutes it just long enough for me to forget that a notification happened

Ok, so assuming we're skipping, I have a different topic

You need Zeno's Calendar Reminder

Does anyone with semantic leanings have a suggestion on how to say "This HTML page is a representation of $URI"?

What does that mean

(and yes, we're talking xmpp: URIs specifically)

alternate?

Zash, I thought so too, but it wants a type (MIME)

it?

IT

pep., http://microformats.org/wiki/rel-alternate#With_type

I've done `<link href="xmpp:jid" rel="alternate"/>` in a bunch of places

Otherwise, it's the closest so far

I would too, but I don't think that's clean enough to spec (or is it?)

I feel like it deserves an explicit type rather than just sniffing the URI

But I may be wrong

isn't there a mime type already?

0081

Can URIs have MIME types?

Ha what

Zash, not URIs but what URIs refer to

What

Retracted though

"in favor of draft-saintandre-xmpp-iri."

ah

I sense a rabbit hole

What's the type of the thing that `mailto:user@host` refers to?

To me this question is nonsense.

That latter draft agrees with you

Zash, well https://foo.bar can be any mime type. https: doesn't really matter

"Because the resource identified by an XMPP IRI/URI does not make available any media type (see [MIME]) and therefore (in the terminology of [URI]) no representation exists at an XMPP resource, the semantics of the fragment identifier component in XMPP IRIs/URIs are to be "considered unknown and, effectively, unconstrained" (ibid.)."

So yeah mimetypes are for the things pointed at, not the pointers

Right

Which brings me back to the beginning... MIME doesn't make sense

Exactly

Ok I didn't get the question then. Missing context

But is rel=alternate with no explanation good enough?

Doesn't it make sense still to have application/xmpp+xml btw? Just like there is application/json, to designate the serialization format

(unrelated to the issue at hand)

I don't think so

So it doesn't make sense to have application/json?

The resource in question isn't data, but a communications endpoint.

hmm

Maybe if you're referencing a specific stanza or pubsub item or something

Right ok so I guess we agree

But that kinda puts you into URL territory

I wasn't thinking about the endpoint thing

Not sure I have an answer to that though

It might be ok to just rel="xmpp"?

Bit redundant with the scheme in the href tho?

Yeah I was gonna say redundant with the scheme ✏

rel="chat" or similar? :/

rel="thethingyoucancommunicateto"

I still think 'alternate' is the closest currently existing thing

At least for things where that URI is equivalent to the page, such as with a web chat

So we'd have to guess from the URI if it's a communication endpoint, an identity, a document, etc. :p

(identity as used by say Mastodon with rel="me")

If you understand XMPP URIs then you'll know what to do with it based on the ?action thing

http://microformats.org/wiki/rel-crush - suddenly rel="xmpp" doesn't seem so bad :)

:D

@rel is a space-separated list, so you can technically just shove in whatever words make sense to you

As it was specified in the question to have semantic leanings, I have to nit a bit here :P "xmpp:foo@bar?pubsub;node=meh" doesn't exactly convey an actionable meaning. I could just want to say such a node exists, I could invite you to publish there (and I'm wondering where that list of query actions is now)

https://xmpp.org/extensions/xep-0147.html there's this but it doesn't seem to include pubsub for example(?)

Surely ?subscribe or ?message are much more explicit

Maybe the issue is just pubsub

Ah it's the registry

https://xmpp.org/registrar/querytypes.html#pubsub Ah wait is it supposed to be xmpp:foo@bar?pubsub;action=subscribe;node=meh ?

TIL XFN, XHTML Friends Network.

A popular explanation of codecs https://youtu.be/-dwLs9juzWw