jdev - 2022-02-28

Messages with any type that's not one of the defined ones (including a missing attribute) default to type="normal". Is there any reason why I'd ever need to distinguish between type="" and type="normal" even though technically they're the same thing?

I'm debating whether it's better to unmarshal XML with type="" into "Type: 'normal'" in the struct I'm using or if it's better to leave the struct with the wire value and only consider an empty attribute to be "normal" when doing any sort of pattern matching on the stanza

Having the user be able to do a naive comparison "msg.Type == 'normal'" would be nice, but I have a vague feeling I'll want the wire value at some point for some reason.

my gut feeling is that belongs higher in the stack, so that the user can always get at the raw XML

but since I know nothing about your library you should take that with a hefty grain of salt

https://xmpp.xa0.uk:5281/upload/azCIolN6-Zwc4coQ/DyqponZW0AEtL8L.jpg

(is it still really a grain at that point?)

everything is relative!

yah, I have the same feeling. I can't think of any reason why that would be the case though.

And the raw xml is already lost, my xml library doesn't preserve it

oh, well if that's the case then maybe doesn't matter

from a debugging POV, it's rough if you say "hey I think your client/server has a bug, but since I can't see the raw xml, it might be my bug"

eg. <a/> and <a></a> are indistinguishable.

Tried to write up all the possible solutions I could think of, and I think I've convinced myself that just doing it at the wire boundary is the best solution.

If we do it during pattern matching it has the issues I already mentioned (plus our stanza matching is modular, users can pull it out and use their own xpath based version, for example, if they wanted and they'd have to know to reimplement this logic there)

If we do something like give messages a TypeAttr() method that returns the normalized type attribute we can compare against that, and still have the original value preserved, but it creates a weird side channel where we decode a message with type="someinfo" and then if we use the same message struct and forward it somewhere else for some reason we send whatever invalid type attribute got sent to us. That feels like some sort of privacy issue waiting to happen.

So maybe just normalizing it when it comes in or goes out over the wire keeps things simple. We won't be able to interface with broken implementations that use their own custom type attributes (and I'd bet those exist), but I'm not sure how important that is.

is there a list of shame anywhere of all the TLDs that don't support DNSSEC ?

Not specifically a list of shame but https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains has all the info

...but can I parse it with grep >_> <_< thanks Sam !