It seems that we have strong, not rough consensus, on the required characteristics of <atom:id>: guaranteed presence, global uniqueness, and immutability. There are a few options before us,
I hope that, based on that, we can rally around one of the syntax options, with strong language in the spec and good validators to get our message across. I suggest that we see if any of the options is substantially more popular than the others, and if so rally around it and get this issue behind us.
Filling Out the Survey
The options we have are:
URI: It's a URI, it MUST be present, globally unique and immutable
Canonical URI: It's a URI, it MUST be present, globally unique and immutable and canonical
String: It's a string of XML characters, it MUST be present, globally unique and immutable
The voting is simple, -1, 0, or 1 based on whether you dislike, are OK with, or really like, the options.
Please Add Yourself to the Survey Below This Line
I would have liked to have seen a qualification around relative URIs - BillDehora
I thought that relative URIs were comprehensively beaten to a bloody pulp -Tim
Exactly - BillDehora
Why are URNs or schemes missing from the survey? I don't think those are beaten to death yet. Maybe add URN to the survey while it's still early. -Elias
URNs are a registered URI scheme - SamRuby
[AsbjornUlsberg] I'll just explain the * on my vote: I'm in sync with Elias here in that we should rather use URN's than any URI.
[ZivCaspi] The * on the URI means this: While the ID itself should be a URI, we should also recommend any re-publisher to preserve the entry as-is. In particular, canonicalization of the ID by any man-in-the-middle should be discouraged.
[MichaelStillwell] Why is there a requirement for global uniqueness? Since this can't be guaranteed (and forging ids has great mischief potential) any service that *needs* a global id will need to generate one itself. (Which would almost always be done via concatenate(feed-url, entry-id), I'd guess.)
[JulianReschke] The canonicalization requirement doesn't make sense to me. If recipients need to compare IDs char-by-char, and need to store them as is, canonicalization doesn't help at all (it would only make sense if we would use a different comparison scheme). Note that I'm not advocating against canonical URIs, I just think that adding the requirement here is needed (I'd understand it as a good practice, but not as a protocol requirement)