Moin. Ja, der „levels“-Tag von vor deiner Änderung war auf jeden Fall verbesserungswürdig. Aber „layer=5“ scheint mir hier nicht ganz passend zu sein, da „layers“ nur die Ordnung zwischen Elementen bestimmen soll. „layers=1“ würde beispielsweise reichen.

Zusätzlich könnte die Höhe mit „building:min_level“ angegeben werden.

Moin! Zusätzlich zu building:parts wird stark empfohlen, das Gesamtgebäude als building-Linie zu kartieren. Es sollte selten building-parts geben, die nicht von einer Gebäude-Linie umschlossen werden.
osm.wiki/DE:Key:building:part

> Only the L7 protocol is specified.

Encryption is another matter. You're assuming that HTTP is non-encrypted, based on the HTTPS pseudo-protocol. There are actually several modes of encryption for HTTP.

Which of these modes is implemented by Wikimedia or how else could that be relevant? The answer is: It is not, "https:" URLs are the only way to retrieve resources from Wikimedia using HTTP. Also, do not confuse protocols with URL schemes. While HTTP does not exclude the usage of TLS, an "http:" URL does most certainly.

What you are referring to is that HTTP is specified separately from encryption. Which is true: A plain HTTP connection will not be encrypted. An "http:" URL refers to such a connection (or an alternate encryption mode, which is not relevant in this case, like in most other cases; and would also involve unencrypted HTTP communication before upgrading the connection).

With an "http:" URL, the client will not immediately know that it has to use a TLS connection until it gets the redirection.

Unless it has some state that tells to rewrite the URL to "https:" in the first place. Which you even mentioned, with HSTS and HTTPS Everywhere. But you wanted to convince me of the advantage of "http:" URLs. If these are only used for the redirect and avoided when the client has better knowledge, why not link to the resource directly?

> > You just assume the client would know to use https instead
> Not at all. You're projecting.

Above, I can read you speaking about HSTS. According to https://https.cio.gov/hsts/, "HSTS exists to remove the need for the common, insecure practice of redirecting users from http:// to https:// URLs." Note that redirecting is considered insecure here.
Where available, it is a good tool to avoid requesting "http:" resources and heading for "https:" URLs instead.

But with your statement "That's what HSTS and HTTPS Everywhere are for" you seem to assume that something alike is present. What about the bot you mentioned? What about a user who has no state from a previous visit? They will first use the URL that is written, thus using an unencrypted HTTP connection, weakening the advantage of HTTPS. If the link itself referred to the secure and correct location, everything would be fine and such mechanisms are not needed.

There are many cases with good reasons to leave redirecting links, e.g. shortlinks. This is not one of those cases.

> > So let me put your question the other way round. Why should it stay "http"?
> Already answered that. See my earlier response.

My fault, now I see it. You claim that "http:" URLs would be more "robust & future-proof". What makes you think this might be the case?

Also, you connected that with another assumption ("when encryption is done using the default port, over the same original connection"); an assumption that just did not hold up in this case.

Furthermore, your salty side-note "instead of 2⁸, because each protocol demands 2" leads me to think you might just not be a fan of dedicated protocol-over-TLS ports.
By the way: half of 2¹⁶ would be 2¹⁵, not 2⁸.

Also, from the same comment: "You're also defeating caching for a resource which is ideal for caching.".
The pictures are not subject to caching by middleware, as they will always be sent out encrypted. Caching a few redirects would be still possible, but is less benecificial than to avoid them.

> The burden of proof is yours; you're asserting that s/^http:/https:/g should be so. This is your changeset, too.

The correct behaviour of OSM is to link to resources by using the correct URL. I tried to replace outdated links by securer and more direct links.

> > "Besides, not all User-Agents need encryption (bots)."
> > They do, because Wikimedia does not support unencrypted HTTP connections. See https://meta.wikimedia.org/wiki/HTTPS for more info.
> LOL, you assume much.

I believe I have proven my "assumption" well, with an article that directly tells that the transition to HTTPS-only has ended.

A "LOL" is a possible answer, but does not help you in making a counter argument.

> Besides scope, Wikipedia insisting on HTTPS isn't a matter of the bot (assuming one which is concerned about fetching from WP) itself needing HTTP+TLS, but the site requiring it. The bot would be perfectly happy without.

Maybe the bot would be "happy" without TLS, but it is still required, so what choice does the client have? What does "happy" mean, by the way?

> Wikipedia does indeed respond to TCP/80, else how does it redirect to TCP/443?

Which is all you will get from "http:" URLs at Wikimedia: A redirect. They redirect to the correct resource, which is behind an "https:" URL. Which in turn is the correct resource locator.

Try it out right now: `curl -v http://meta.wikimedia.org/wiki/HTTPS` for example, if you have curl installed.
You will not get the desired resource, but a redirection to its correct location: "Location: https://meta.wikimedia.org/wiki/HTTPS"

The TCP/80 webserver is only present for backwards compatibility with older URLs and the like.

I have to rephrase my sentence to "Getting content on Wikimedia requires requesting an HTTPS URL", though. Requesting the "http:" resource beforehand is not necessary or constructive, as the location has changed.

> Sounds like you don't understand relevant networking, either.

Your opinion that "http:" URLs have to stay indefinitely is not the prevailing one in the IT industry and seems technically not very grounded. It staggers me you have no insight in this and even start to make insulting assumptions about people.

> > "the bbox is nebulous."
> > Which is the case every time you edit France or the United Kingdom.
> Relevance for this changeset?

In this changeset, I edited at least one country which generates a big changeset bounding box when changed. When noting a "nebulous" bbox, I assumed you were referring to its size.

> Your failure to read documentation causes extra changesets, due to the needed reversion.
It is still 2 changesets – versus many more, if I used one CS for one country. Your impression of "extra changesets" seems to be not correct.

> > I could understand the whish to remove the "flag" tags everywhere. But not the whish to keep "http" links.
> That's not a technical or OSM matter / problem.

I do not fully understand the motivation behind this sentence. Both intents would be only fulfilled by adjusting tags, which could be achieved by a changeset like this.

Again, this was not a mechanical or half-automated edit. I just selected objects with iD and discovered and changed tag values that were a bit outdated. Just that countries are a bit harder to select than other objects.

I think smaller changeset bounding boxes would be nice. These are only a few benches added, one of them not even in Europe.

See osm.wiki/Changeset#Geographical_size_of_changesets

Hey, welcome to OSM.

May I recommend this wiki article to you? osm.wiki/Changeset#Geographical_size_of_changesets

This changeset was done manually with iD.

Yes, it could be considered wide-ranging. Which is but out of scope for the wiki article you posted.

"Why?"
"http:" links refer to unencrypted HTTP resources and should not appear anywhere where TLS is available. You just assume the client would know to use https instead, but this is not always the case. So let me put your question the other way round. Why should it stay "http"?

"Besides, not all User-Agents need encryption (bots)."
They do, because Wikimedia does not support unencrypted HTTP connections. See https://meta.wikimedia.org/wiki/HTTPS for more info.

"the bbox is nebulous."
Which is the case every time you edit France or the United Kingdom.

Separating the edits would generate more edits in almost every watched bounding box.

I could understand the whish to remove the "flag" tags everywhere. But not the whish to keep "http" links.

Yes, flag is used in two ways.

flag:wikimedia_commons would indeed be better, but that should probably be a mechanical edit at some point in the future.

There are still many states left: https://overpass-turbo.eu/s/1fNe

Thank you 👍

I am sorry, I meant 117027856.

Hey, I think the revert is not complete, with that 'name' tag. 117027926 seems not reverted.

"Republic of Frank Mortenson" sounds very unlikely.

Thanks for pointing out!

I got indeed no reply on my DM.

DWG blocked the account and waits for the owner to contact them.

Yes, my comments on changeset/115061760 and changeset/115683043 were unanswered as well. I sent a DM now, hopefully the owner will read at least that.

Please do not edit special character tags until your Editor's encoding issue is resolved. Repaired in changeset/116517030.
---
#REVIEWED_BAD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/116515852

Is it maybe protect_level=2? admin_level=2 would mean this is a (national) state boundary.

Hi! Are you sure about the admin_level=2 in the boundary relation?

Scheint jetzt https://cafelutetia.eatbu.com/ zu sein.