Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Don't repair RFC-conform UIDs by default #527
Why is @ not in the list of safe chars for UIDs? (See PR #231.) If one follows the RFC's recommendations (see https://tools.ietf.org/html/rfc5545#section-18.104.22.168), then an @ is bound to be there. Now what happens when doing a repair, e.g., due to some duplicate UID, then almost all entries will have their UID changed. In case the entry creator used a creation date as the start of the UID (as recommended), this actually causes convenient info to be lost. Namely, if one looks at the entries in the directory listing, one won't be able to use a nice ordering.
I'd like to request putting @ in the list of safe chars for UIDs.
I'm aware that @ is a reserved character and that means that in principle it should be encoded in URLs, but this consideration should not affect restrictions imposed on the UID.
added a commit
Dec 5, 2016
Also this is wrong, it's a totally safe character in URL paths in theory.
In the past vdirsyncer attempts to make
I guess you're referring to Issue #526. Well, that is a server bug, no? If the server can't deal with UIDs in a form that is recommended by the RFC…
Also, we don't how do the myriad of clients react when they see all the UIDs have changed. I guess they think all existing entries are gone and an equal number of new ones appeared. Again, any state based on UID will be lost. And keeping state based on UID is not crazy, as I think UIDs are assumed to be ‘somewhat constant’ next to being unique.
I think I agree with you here, https://tools.ietf.org/html/rfc3986#section-2.2 says:
Given that @ would not conflict when in the path part of a URL, it does not need to be encoded.
Unfortunately those servers are sufficiently popular to make this such a practical issue such that the principle of only following the RFC is (in my view) outweighed.
Or rather, they may not even be that popular, but I got enough bugreports about this to be annoyed enough to add this fixer.
Vdirsyncer already maintains the invariant that
That is a very good argument. I didn't realize that I would actually break anything with doing "too much" repair. I think we should have this repair routine disabled by default then.
The argument is even simpler. If you look at the ABNF for