<div dir="ltr">The unfortunate side of things is that systemd uses an _ as an escape character for hex-encoding, and this proposal is incompatible with that, since we lose that ability. I certainly don't want to bikeshed too much, but I kind of like using _ for hex escapes more. It's uglier, but more universal.</div><div class="gmail_extra"> <div class="gmail_quote">On Mon, Oct 16, 2017 at 5:54 AM, Simon McVittie <<a href="mailto:smcv@collabora.com" target="_blank">smcv@collabora.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 16 Oct 2017 at 14:16:05 +0200, Matthias Klumpp wrote: > Is there a chance that DBus and other tools can get rid of the naming > limitations anytime soon? Or does the "no-digit-start, no-dash" rule > have to stay forever? Given the number of D-Bus implementations floating around, and the historical behaviour of the reference implementation (libdbus enforces syntax rules strictly but historically didn't have public API to do the necessary checks, so every language binding had to NIH the correct validation), I think that would be an incompatible change of the sort that we Do Not Do. Also, encouraging underscores and deprecating dashes would align the recommended character set for D-Bus well-known names with the required character set for D-Bus interface names, which are more strict than well-known names (and in particular have never allowed dashes). Interface names are designed to be usable in code generation (e.g. some C++ bindings would map D-Bus com.example.MyInterface.MyMethod to C++ com::example::MyInterface::MyMethod) which I believe is why we never allowed dashes and leading digits there, and should not in future. > Urgh, that is definitely a bug, AppStream should allow underscores for > sure. I will fix that with the next release. Thanks! > The AS spec should > really allow underscores, because they are an allowed character in > domain names, so that part is just a bug, and likely my mistake. Underscores are an allowed character in the DNS protocol. They are *not* an allowed character in domain names[1], and that's why replacing dashes with underscores does not risk collisions: the owner of <a href="http://awesome-software.com" rel="noreferrer" target="_blank">awesome-software.com</a> is free to use com.awesome_software in their desktop file ID, D-Bus API, AppStream etc. in the knowledge that they are not conflicting with the owner of <a href="http://awesome_software.com" rel="noreferrer" target="_blank">awesome_software.com</a>, because <a href="http://awesome_software.com" rel="noreferrer" target="_blank">awesome_software.com</a> cannot exist. (This is also why underscores are used in DNS SRV: they're allowed in the DNS protocol, but cannot appear in hostnames or domain names, so the special SRV DNS names like _ipp._<a href="http://tcp.example.com" rel="noreferrer" target="_blank">tcp.example.com</a> cannot collide with anyone's hostname or domain name.) However, underscores are an allowed character in D-Bus well-known names, and the recommended syntax for desktop file IDs is a D-Bus well-known name, which suggests that designs that reflect or mimic desktop file IDs (like the AppStream <id>) should probably allow underscores anyway. smcv [1] <a href="https://tools.ietf.org/html/rfc1035" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc1035</a> "The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen." <div class="HOEnZb"><div class="h5">_______________________________________________ Flatpak mailing list <a href="mailto:Flatpak@lists.freedesktop.org">Flatpak@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/flatpak" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/flatpak</a> </div></div></blockquote></div> <div> </div>-- <div class="gmail_signature" data-smartmail="gmail_signature"> Jasper </div> </div>