> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
I don't think this specification specifically needs to be defined in the
XMPP protocol stack, but I do think it's nice to have a recommended
method for doing this. If there are other already-standardized ways of
doing this, I would prefer that we adopt one of those instead of doing
our own. I don't actually know if there are any though, and am happy for
it to be standardized here as well if there aren't.
> 2. Does the specification solve the problem stated in the introduction
> and requirements?
I have only implemented an older version of this specification which I
intend to continue using and it solves the problem well enough. I am not
qualified to know whether it addresses the accessibility requirements,
but as far as I can tell it does. I have no reason to believe that the
current, more up-to-date version does a worse job at this, so I suspect
it still solves all the problems and meets all the requirements.
> 3. Do you plan to implement this specification in your code? If not,
> why not?
I have implemented an older version, but do not plan on implementing the
current version. If we are going to standardize this we should be using
existing standard color spaces that are widely implemented. In the
latest version a color space that was defined by an individual and is
not otherwise widely used has been adopted, which I feel isn't the right
way to go about any standards development.
I am sure critics will counter with "but it's so easy to implement, and
the author has libraries in various languages", but never the less it is
my belief that we should stick to widely used and widely vetted color
spaces from other standards bodies, and not just whatever trendy new
thing one or two people on hacker news have created this week. We are
just making more work for ourselves by going this route.
I should not have to vet a color space and a library that an individual
made, and I am likely not qualified to do so. As a standards body we
should re-use other standards bodies work unless there is a very good
reason not to, and I don't believe there is one here. We should go back
to a color space that is already used in the industry, or at least hold
off advancing this XEP until we're sure the colors space that has been
picked is actually being widely adopted itself.
> 4. Do you have any security concerns related to this specification?
It's worth mentioning that any sort of color hash like this will be
somewhat limited and that the human eye can only distinguish between so
many colors, so it shouldn't be used to do things where the user would
have to discern uniqueness. ie. if the user has two contacts that both
hash to the same color (or close to the same color), they could become
confused about who is speaking and who they're writing to if this isn't
paired with other visual indicators that differentiate the contacts.
> 5. Is the specification accurate and clearly written?
Yes, it's easy enough to follow along with.
—Sam
On 3/10/24 10:24, Daniel Gultsch wrote:
This message constitutes notice of a Last Call for comments on
XEP-0392.
Title: Consistent Color Generation
…
URL: https://xmpp.org/extensions/xep-0392.html
This Last Call begins today and shall end at the close of business on
2024-03-25.
--
Sam Whited
[email protected]
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
