-
Notifications
You must be signed in to change notification settings - Fork 76
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
Allow @ in tracestate key names for multi-tenant vendors #153
Conversation
## Vendor name in a key | ||
|
||
Sign `@` is allowed in a key for easy parsing of vendor name out of tracestate key. Idea is that with the registry of trace vendors one can easily understand the vendor name and how to parse it's trace state. Without `@` sign parsing will be more complicated. Also `@` sign has known semantics in | ||
addressing for protocols like ftp and e-mails. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unintentional line-break?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's markdown
## Vendor name in a key | ||
|
||
Sign `@` is allowed in a key for easy parsing of vendor name out of tracestate key. Idea is that with the registry of trace vendors one can easily understand the vendor name and how to parse it's trace state. Without `@` sign parsing will be more complicated. Also `@` sign has known semantics in | ||
addressing for protocols like ftp and e-mails. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, not sure if "Also @
sign has known semantics in addressing for protocols like ftp and e-mails" really adds a lot here. Would it hurt to remove this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's fine. Any way to explain it easier?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I't ok, I'm also fine with keeping this.
lcalpha = %x61-7A ; a-z | ||
``` | ||
|
||
Note that identifiers MUST begin with a lowercase letter, and can only contain lowercase letters `a`-`z`, digits `0`-`9`, underscores `_`, dashes `-`, asterisks `*`, and forward slashes `/`. | ||
Note that identifiers MUST begin with a lowercase letter, and can only contain lowercase letters `a`-`z`, digits `0`-`9`, underscores `_`, dashes `-`, asterisks `*`, and forward slashes `/`. For multi-tenant vendors scenarios `@` sign can be used to prefix vendor name. Suggested use is to allow set tenant id in the beginning of key like `fw529a3039@dt` - `fw529a3039` is a tenant id and `@dt` is a vendor name. Searching for `@dt=` would be more robust for parsing (searching for all vendor's keys). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you all are way too quick to make decisions like this.
for posterity there was mention about no objections. in the doc it also
said that many people were only partially available monday. can folks that
agree we should document this practice please make yourselves known, or at
least say who was present when no objections were claimed?
it is good to make decisions but it should be transparent which
"implementors" will be using this and how. I am not saying this is a bad
call just didn't see folks outside DT talking about their use cases for
this.
|
#137