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.
@@ -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
@@ -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.