New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion: UUID URN Extension #4
Comments
Tossing in my 2 cents:
{
"new_uuid": {
"uuid": "73e94fe0-e951-4153-aaf3-50e4e6089d9d",
"length": "128",
"encoding": "base16hd"
}
} As such the draft should also specify something like this as an alternative to URN if an implementation desires. |
I think the JSON description of the UUID should:
With such a detailed and flexible description of the UUID, there is no need to specify the version and variant. I also think we need a naming convention for functions for generating, parsing, changing the encoding, hash function (to 128 bits) and other UUID manipulations. We should drop the requirement that the length of UUID segments be divisible by 8, 4, 5, etc. We should drop the requirement for millisecond accuracy, as it is not enough inside the data processing center. Maybe 10 microseconds would be better. Let the implementer decide. We may recommend different JSON descriptions of the UUID for different purposes and circumstances as well as the default layout for most uses. |
Different draft spec; this topic is not valid for this document.
Natural byte boundaries make sense as a general recommendation. But you are adding way more discussions to this thread than the original purpose. Remember to keep on topic, we are discussing URN extension only here.
Another off topic: This specific spec will make no changes to UUID var/ver in it's current form. Otherwise, yeah, nothing stopping you from doing the rest of the things you said. The main goal of the proposed URN extension in this spec is to provide a "well-known with UUID" standards-based method of solve two problems below for features introduced by this draft spec:
The point I was making is that the text should specify that it is valid for somebody to use JSON (or any data structure: XML, YAML, SDP, GPB, BSON, etc.) as an alternative to an Extended UUID URN for conveying the two points above. Anything else they want to convey in that alternative format is up to the implementation and beyond the scope of what the problems the UUID URN extension is trying to solve. |
@kyzer-davis, You set insignificant goals that do not require the development of a new standard at all. The already published draft is enough. After all, no one forbids adding metadata to the right of the UUID (for example, they already add a checksum) or showing the UUID in any encoding. Such insignificant goals will not inspire enthusiasts. Therefore, this venture is doomed. But you overlooked the great potential of describing a detailed UUID structure (in JSON format) apart from the UUID itself and apart from the standard and the great potential of using that UUID structure description as a parameter to a function that generates a UUID. |
I think you misunderstand, I am not saying the idea has no merit at all. I just don't see a reason for it to be a part of the Draft for v6/7/8/max or within this draft which deals solely with documenting how implementers can utilize alternate encoding techniques and variable length/longer length UUIDs. After all, the reason we split these two topics out is due to scope creep of the original draft. If we keep adding topics the drafts will never be complete (and I have already been working on them for 2 years). With that I will defer to others in the community for further feedback on your proposal:
|
All things UUID URN as a way to convey extra information about the underlying UUID value.
The current problem that needs solved, which are introduced via alternate encoding and a longer UUID length is as I described earlier:
Key things to keep in mind:
Edit: The main goal of the proposed URN extension in early draft-00 for this spec is to extend the already allocated IANA UUID URN and describe length and encoding in a way that decouples it from the UUID and is compatible with all UUIDs and URNs out there today.
See my previous comment for rational behind placement of current values in UUID URN:
#2 (comment)
The text was updated successfully, but these errors were encountered: