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

cap/tags: Specify that idents are to be parsed as opaque identifiers #274

Merged
merged 7 commits into from Oct 17, 2016
@@ -166,6 +166,8 @@ continue as normal.
## Rules for naming capabilities
The full capability name MUST be treated as an opaque identifier.
There are two capability namespaces:
### Vendor-Specific
@@ -176,7 +178,7 @@ These names are prefixed by a valid DNS domain name.
For example: `znc.in/server-time`.
In cases if the domain name contains non-ASCII characters, punycode MUST be used,
In cases where the prefix contains non-ASCII characters, punycode MUST be used,
e.g. `xn--e1afmkfd.org/foo`.
Vendor-Specific capabilities should be submitted to the IRCv3 working group for consideration.
@@ -219,3 +221,7 @@ specification.
Previous versions of this spec did not specify how to handle CAP LS when a server did not support
any capabilities. This was clarified to match CAP LIST, requiring a reply with an empty parameter.
Previous versions of this spec did not specify that the full capability name MUST be treated as
an opaque identifier. This was added to better suit real-world usage and to improve client
resiliency.
View
@@ -69,6 +69,8 @@ Also having semicolon as `\:` makes it easy to split the `<tags>` string by `;`
## Rules for naming message tags
The full tag name MUST be treated as an opaque identifier.
There are two tag namespaces:
### Vendor-Specific
@@ -78,7 +80,7 @@ These names are prefixed by a valid DNS domain name.
For example: `znc.in/server-time`.
In cases if the domain name contains non-ASCII characters, punycode MUST be used,
In cases where the prefix contains non-ASCII characters, punycode MUST be used,
e.g. `xn--e1afmkfd.org/foo`.
Vendor-Specific tags should be submitted to the IRCv3 working group for consideration.
@@ -109,6 +111,10 @@ Message with 3 tags:
* tag `ddd` specific to software of `example.com` with value `eee`
## Errata
Previous versions of this spec did not specify that the full tag name MUST be parsed as
an opaque identifier. This was added to improve client resiliency.
[rfc1459]: http://tools.ietf.org/html/rfc1459#section-2.3.1
View
@@ -66,6 +66,8 @@ prefixed the same way as how vendor-specific capabilities are prefixed.
See [capability negotiation](../core/capability-negotiation-3.1.html) for the
exact details.
The full batch type name MUST be treated as an opaque identifier.
While batch types are similar to capabilities in this aspect, unlike
capabilities, batch types are not advertised by servers nor explicitly
requested by clients.
@@ -117,3 +119,8 @@ Notice that PRIVMSG line will be processed when batch `outer` ends,
because end of batch `inner` is tagged by batch `outer`.
The order in which these two batches start doesn't matter.
## Errata
Previous versions of this spec did not specify that the full batch type name MUST be parsed as
an opaque identifier. This was added to improve client resiliency.
ProTip! Use n and p to navigate between commits in a pull request.