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

Add rewritten metadata specification #250

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
2 participants
@attilamolnar
Member

attilamolnar commented Mar 16, 2016

TODO:

  • Update numerics to match inspircd implementation
  • Rewrite to include the parts of 3.2 that still apply, clarifying if necessary and mention that 3.2 is deprecated (see #279)
  • Add a requirement that clients should expect to receive notifications even if they haven't subscribed to any key, e.g. if a server needs to update a client's own metadata, e.g. on oper, or auth, or if an oper sets a key on another user.
  • Specify a cap value that advertises a limit of key and/or value names
  • Drop the 3.3 versioning. (see #265)
  • #278 Additional non-normative sections
  • Remove RPL_METADATAEND replies, clients should use labeled-response
  • Allow async processing of requests
  • Change ERR_KEYINVALID to drop the message reason and include the invalid key as the last arg since it could contain spaces
  • Clarify ERR_KEYNOPERMISSION to expand "not settable by the requesting user" with "or otherwise disallowed by the server"
  • Allow hyphens in key names

Discuss:

  • Rename CAP to just metadata (no need for version number, values are about more than notifications)
Show outdated Hide outdated extensions/metadata-3.3.md Outdated
@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 16, 2016

The key subscription needs to be disclosed to the client somewhere, e.g. via a METADATA key on RPL_ISUPPORT.

ghost commented Mar 16, 2016

The key subscription needs to be disclosed to the client somewhere, e.g. via a METADATA key on RPL_ISUPPORT.

@jwheare jwheare referenced this pull request Mar 16, 2016

Closed

Metadata tracker #244

2 of 7 tasks complete
@attilamolnar

This comment has been minimized.

Show comment
Hide comment
@attilamolnar

attilamolnar Mar 16, 2016

Member

The key subscription needs to be disclosed to the client somewhere, e.g. via a METADATA key on RPL_ISUPPORT.

I don't exactly understand what you mean. Can you elaborate? If this is about advertising the availability of the new subcommands, the presence of metadata-notify-2 implies support for them.

Member

attilamolnar commented Mar 16, 2016

The key subscription needs to be disclosed to the client somewhere, e.g. via a METADATA key on RPL_ISUPPORT.

I don't exactly understand what you mean. Can you elaborate? If this is about advertising the availability of the new subcommands, the presence of metadata-notify-2 implies support for them.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 16, 2016

Sorry, I missed a word there; the key subscription limit needs to be disclosed.

ghost commented Mar 16, 2016

Sorry, I missed a word there; the key subscription limit needs to be disclosed.

@attilamolnar

This comment has been minimized.

Show comment
Hide comment
@attilamolnar

attilamolnar Mar 16, 2016

Member

I agree, that should be advertised. I think it should be in the cap's value because we can't change the format of the value of the METADATA ISUPPORT token after release and adding a new ISUPPORT token is not necessary if there is a cap already.

Member

attilamolnar commented Mar 16, 2016

I agree, that should be advertised. I think it should be in the cap's value because we can't change the format of the value of the METADATA ISUPPORT token after release and adding a new ISUPPORT token is not necessary if there is a cap already.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 16, 2016

I disagree; the METADATA token could be changed to use the same key/value format other RPL_ISUPPORT tokens use (TARGMAX, for instance), and clients should be able to figure out which version is which trivially.

ghost commented Mar 16, 2016

I disagree; the METADATA token could be changed to use the same key/value format other RPL_ISUPPORT tokens use (TARGMAX, for instance), and clients should be able to figure out which version is which trivially.

@jwheare

This comment has been minimized.

Show comment
Hide comment
@jwheare

jwheare Mar 16, 2016

Member

Changing the ISUPPORT format only if the CAP is negotiated seems reasonable.

Member

jwheare commented Mar 16, 2016

Changing the ISUPPORT format only if the CAP is negotiated seems reasonable.

@attilamolnar

This comment has been minimized.

Show comment
Hide comment
@attilamolnar

attilamolnar Mar 16, 2016

Member

I disagree; the METADATA token could be changed to use the same key/value format other RPL_ISUPPORT tokens use (TARGMAX, for instance), and clients should be able to figure out which version is which trivially.

Clients released before this specification can't figure out "which version is which" because they expect a single integer as the value of the ISUPPORT token.

Changing the ISUPPORT format only if the CAP is negotiated seems reasonable.

Clients can request metadata-notify-2 after ISUPPORT (say after they receive a CAP NEW) and they won't get the value that way. Also existing servers have a cached ISUPPORT and send that to all clients. Having per client ISUPPORT is something they'd have to add support for separately for this case and it has no benefit over advertising as a cap value. (In fact, the cap value has benefits as it allows changing the limit on the fly for example).

Member

attilamolnar commented Mar 16, 2016

I disagree; the METADATA token could be changed to use the same key/value format other RPL_ISUPPORT tokens use (TARGMAX, for instance), and clients should be able to figure out which version is which trivially.

Clients released before this specification can't figure out "which version is which" because they expect a single integer as the value of the ISUPPORT token.

Changing the ISUPPORT format only if the CAP is negotiated seems reasonable.

Clients can request metadata-notify-2 after ISUPPORT (say after they receive a CAP NEW) and they won't get the value that way. Also existing servers have a cached ISUPPORT and send that to all clients. Having per client ISUPPORT is something they'd have to add support for separately for this case and it has no benefit over advertising as a cap value. (In fact, the cap value has benefits as it allows changing the limit on the fly for example).

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 16, 2016

Clients released before this specification can't figure out "which version is which" because they expect a single integer as the value of the ISUPPORT token.

This is a valid criticism.

Changing the ISUPPORT format only if the CAP is negotiated seems reasonable.

This is a terrible idea.

ghost commented Mar 16, 2016

Clients released before this specification can't figure out "which version is which" because they expect a single integer as the value of the ISUPPORT token.

This is a valid criticism.

Changing the ISUPPORT format only if the CAP is negotiated seems reasonable.

This is a terrible idea.

@attilamolnar

This comment has been minimized.

Show comment
Hide comment
@attilamolnar

attilamolnar Apr 27, 2016

Member

What's the status of this? Do we need implementations for this to move forward?

Member

attilamolnar commented Apr 27, 2016

What's the status of this? Do we need implementations for this to move forward?

@jwheare

This comment has been minimized.

Show comment
Hide comment
@jwheare

jwheare Apr 27, 2016

Member

Yes, and I think it should be merged with #245 so we can point to a single PR from the tracker issue.

Member

jwheare commented Apr 27, 2016

Yes, and I think it should be merged with #245 so we can point to a single PR from the tracker issue.

@attilamolnar

This comment has been minimized.

Show comment
Hide comment
@attilamolnar
Member

attilamolnar commented Apr 27, 2016

Somewhat experimental implementation here: https://github.com/attilamolnar/inspircd/tree/master%2Bmetadata

@jwheare jwheare referenced this pull request Nov 18, 2016

Closed

Problems with metadata #219

@attilamolnar attilamolnar changed the title from Add metadata-3.3 specification to Add rewritten metadata specification Nov 22, 2016

@attilamolnar

This comment has been minimized.

Show comment
Hide comment
@attilamolnar

attilamolnar Jan 6, 2017

Member

More ideas: Remove the End of metadata numeric sent in reply to every METADATA command, clients that want to track when the reply ends should use labeled-response. Also allow the server to asynchronously process any METADATA request (but still in order).

Member

attilamolnar commented Jan 6, 2017

More ideas: Remove the End of metadata numeric sent in reply to every METADATA command, clients that want to track when the reply ends should use labeled-response. Also allow the server to asynchronously process any METADATA request (but still in order).

@jwheare jwheare added the metadata label Jan 7, 2017

@jwheare jwheare added this to the Roadmap milestone Jan 7, 2017

@jwheare jwheare referenced this pull request Feb 22, 2018

Open

Metadata key proposals #336

jwheare added a commit to jwheare/ircv3-specifications that referenced this pull request Apr 11, 2018

@jwheare jwheare referenced this pull request Apr 11, 2018

Open

[WIP] Merged metadata rewrite #339

8 of 12 tasks complete
@jwheare

This comment has been minimized.

Show comment
Hide comment
@jwheare

jwheare Apr 11, 2018

Member

Closing in favour of #339

Member

jwheare commented Apr 11, 2018

Closing in favour of #339

@jwheare jwheare closed this Apr 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment