XSF Discussion - 2019-06-29

can someone with URI knowledge tell me whether: `xmpp://xmpp-public.sotecware.net:5222/sotecware.net` would be an accurate way to write "Connect to sotecware.net using xmpp-public.sotecware.net on port 5222, skipping SRV record resolution"? ✏

it does not need to be generally understood that it means that, just whether the basic URI semantics are sane

jonas’: you don't need the domain if you have a jid to get it from

moparisthebest, depends on the use-case

You probably need a jid regardless don't you?

I want this for monitoring purposes, so I might want to monitor the up-ness and certificates and stuff of all possible server endpoints for a given domain

yes, the jid is behind the last ``/``

it’s just a domain, but still a JID :)

(in the specific case I’m thinking about, the client would never even authenticate, so there’s no need for a valid localpart)

I’m trying to coerce this into a single URI/URL because I only have a single string to pass to stuff.

I have a thing that accepts domain@host:port (not an URI/URL)

Ah ok, I made up my own similarish url syntax for this and ralphm yelled at me lol https://github.com/moparisthebest/jDnsProxy/blob/master/xmpp-dox/jdnsproxy.xmpp.resolver.properties#L27

I also needed a single string

🤣

so maybe ralphm can now also yell at me?

Yelling As A Service?

Yaas

Real-Time Instant Yelling Service

In general, yes, if it looks like a URI, just make it one. Especially if you're using existing URI schemes.

Also, I generally don't like it when people use new schemes in production without having IANA registering it first.

jonas’: but specifically, no, you can't bypass SRV like that. It is explicitly forbidden: https://tools.ietf.org/html/rfc5122#section-5.2

ralphm: That's pretty widespread these days, particularly on mobile platforms where apps register their own URL schemes. Almost all modern OS vendors allow apps to define these.

waqas: doesn't mean I have to like it

Or that it is a good idea

I have mixed feelings about it. I'm not necessarily fully sold on IANA registry being a registry of all allowed schemes.

(the same way I'm not sold on all possible XMPP protocol extensions requiring going through the XSF XEP process, the X for extensibility without relying on central authority is important)

Well, either it is a URI, which requires registration with IANA, or it is a fake.

Same for XEPs?

Similarly, without a XEP, you cannot use urn:xmpp as a prefix

I'm comfortable with urn:xmpp, and I'd be comfortable with an app using "http:" to always mean the HTTP protocol.

But all URL schemes requiring registration is like requiring all namespaces even without the urn:xmpp prefix requiring the same

If you don't use the XSF, you must use your own namespace, e.g. one with a http scheme with an auth part that points to your own domain. Or your own registered URN prefix.

It's the registration bit that I'm rejecting

E.g. at Mediamatic, we had namespaces starting with http://mediamatic.nl/ns

`xmlns="xmpp:prosody.im/stuff"` :D

waqas: why? URI/URL/URN as concepts are defined by the IETF, the set the rules.

Isn't there a DNS tree you can use somewhere? `urn:dns:example.com:whatever` ?

Is there a statement from the IETF classifying unregistered as fake?

I haven't considered using xmpp: as a prefix for namespaces. I suppose you can, without auth part like that.

ralphm: Should be equivalent to http:// URLs as namespaces as far as anything is concerned, right?

Indeed

But without auth part (//) because xmpp URIs have specific syntax.

Tho the original topic was overlap between URLs and configuration syntax.

You could spare your sanity and imagine that they're not really UR[LI]s

I think, waqas, you should read RFC 3986 and BCP 35.

Zash: indeed

E.g. by not using an explicit scheme

Is there something like vendor prefixes for schemes?

Yes

As in, foocorp-thing://magic/syntax

See BCP 35, section 3.8.

Basically reversed domain

Like org.example:

`com.foocorp.thing://blah` ?

Also don't use // if it doesn't make sense

I distinctly remember that some platform required it. iOS maybe?

Leading to weird horrors like `xmpp:///stuff`

section 6 of BCP 35 is relevant

That platform is wrong

For the most part, platform vendors and app authors have shown little to interest in BCP 35 though :)

Zash: but I guess Apple has more issues like that, e.g. the recent openid connect thing.

waqas: that doesn't mean you shouldn't

I mildly equate this to the bazaar ignoring the cathedral except for a few popular occasions :)

I hold some pride in doing it properly.

"properly" is up for debate

It is not, though. If you can diverge from standards on a whim, why have them?

Anarchy! Chaos! Cats and dogs living together!

It would be ridiculous to follow all standards. Much like how we don't actually want clients to follow *all* the XEPs.

There's a reason why we made xmpp extensible, so you can choose to do something else without violating specifications.

Indeed, and URI schemes are similarly extensible :)

Yes, when folding its standards.

Of course many people ignore standards

(following)

waqas: > (the same way I'm not sold on all possible XMPP protocol extensions requiring going through the XSF XEP process Where did you get this from?

More than sometimes, not following a standard means pain later.

I think this is just fundamental disagreement, I disagree with following all possible standards being a requirement. I'm sure in any large pool of standards, I'd consider a significant portion to be inappropriate to implement.

You generally don't have to implement all standards?

No, I do not

ralphm: "Pain for someone else" ?

If you just follow XMPP Core, you can call yourself an XMPP application.

If you want to use jabber:iq:roster, please follow what's in XMPP IM, though.

(technically you can call yourself that even when not following Core fully, which is true for most XMPP software, but I digress)

You can, but you would not be truthful.

ralphm: I agree with that! Similar to how I agree followers of HTTP should follow the HTTP specs for the most part!

The world is a lie then. Point out any large code base implementing any large spec and I can probably show you it's a lie.

But anyway, this is going way offtrack :)

I'm cool with central registration being a MAY or SHOULD, but am fundamentally opposed to MUST, particularly for toy, experimental or private use cases, but in general too.

A world where MUST was e.g., a legal requirement would be a worst world, IMHO

There are usually recommendations for private namespaces and such

And people SHOULD follow those when sane :)

I think the text in the specs I linked are to be interpreted mostly as a strong SHOULD, but things will break if you have naming conflicts.

Sure, and in various situations that can be an acceptable tradeoff

Particularly in situations where anonymity is a requirement. Registration with authority generally translates into breaking anonymity.

Except when it doesn't when later your internal thing became part of a public API and now somebody, usually you, is crying.

I imagine that's pretty rare. Most things end up registering when they become big, often turning into de facto standards, and not when they are initially created.

I can't recall if this was true for xmpp: too. Did it see usage before it was registered or after?

I don't directly see how anonymity is a factor in choosing a URI scheme, especially if there's a defined way to do private extensions.

No, xmpp didn't exist as such before interacting with IETF.

`jabber:` then?

We had to grandfather a bunch of things, and the jabber prefix was indeed wrong.

I mean, was there ever a `jabber` URI scheme?

We first changed that to http URIs at jabber.org, eg pubsub, then went on to URNs.

I'm curious if all the XMPP proprietary competitors have their protocols registered :)

They all have at least one each, that their mobile apps register

You *don't* have to register your proprietary extensions.

However, those can't use the urn:xmpp prefix compliantly.

Yep, and my point for URI schemes is that in practice anything not registered via IANA has been fair game for private use. With rare exceptions, the industry as a whole treats things that way.

Well, they get to enjoy their time boms then.

There are easily more than a single order of magnitude schemes out there in use vs what's in the IANA registry

Oh, `jabber` is registered? https://www.iana.org/assignments/uri-schemes/perm/jabber

Yes retroactively

And with all known uses from XEPs and RFCs

Only

That's good.

As I said: grandfathered

https://twitter.com/matrixdotorg/status/1144918306211684352

I think we should definitly do some benchmarks between our XMPP servers and Matrix servers on similar features

Which "we"?

The royal "we"

Zash you and me

Lies, damned lies, statistics, benchmarks.