Skip to content
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
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion core/capability-negotiation-3.1.md
Original file line number Original file line Diff line number Diff line change
Expand Up @@ -166,6 +166,8 @@ continue as normal.


## Rules for naming capabilities ## Rules for naming capabilities


The full capability name MUST be treated as an opaque identifier.

There are two capability namespaces: There are two capability namespaces:


### Vendor-Specific ### Vendor-Specific
Expand All @@ -176,7 +178,7 @@ These names are prefixed by a valid DNS domain name.


For example: `znc.in/server-time`. 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`. e.g. `xn--e1afmkfd.org/foo`.


Vendor-Specific capabilities should be submitted to the IRCv3 working group for consideration. Vendor-Specific capabilities should be submitted to the IRCv3 working group for consideration.
Expand Down Expand Up @@ -219,3 +221,7 @@ specification.


Previous versions of this spec did not specify how to handle CAP LS when a server did not support 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. 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.
8 changes: 7 additions & 1 deletion core/message-tags-3.2.md
Original file line number Original file line Diff line number Diff line change
Expand Up @@ -69,6 +69,8 @@ Also having semicolon as `\:` makes it easy to split the `<tags>` string by `;`


## Rules for naming message tags ## Rules for naming message tags


The full tag name MUST be treated as an opaque identifier.

There are two tag namespaces: There are two tag namespaces:


### Vendor-Specific ### Vendor-Specific
Expand All @@ -78,7 +80,7 @@ These names are prefixed by a valid DNS domain name.


For example: `znc.in/server-time`. 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`. e.g. `xn--e1afmkfd.org/foo`.


Vendor-Specific tags should be submitted to the IRCv3 working group for consideration. Vendor-Specific tags should be submitted to the IRCv3 working group for consideration.
Expand Down Expand Up @@ -109,6 +111,10 @@ Message with 3 tags:


* tag `ddd` specific to software of `example.com` with value `eee` * 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 [rfc1459]: http://tools.ietf.org/html/rfc1459#section-2.3.1
7 changes: 7 additions & 0 deletions extensions/batch-3.2.md
Original file line number Original file line Diff line number Diff line change
Expand Up @@ -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 See [capability negotiation](../core/capability-negotiation-3.1.html) for the
exact details. 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 While batch types are similar to capabilities in this aspect, unlike
capabilities, batch types are not advertised by servers nor explicitly capabilities, batch types are not advertised by servers nor explicitly
requested by clients. requested by clients.
Expand Down Expand Up @@ -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`. because end of batch `inner` is tagged by batch `outer`.
The order in which these two batches start doesn't matter. 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.