cjus

Hey everyone. This may be a bit out there. I'm a developer and certified instructor in Qigong - an ancient mind body practice. Some months ago I decided to apply AI to create modules that support the exploration of these mind body practices. Would love some feedback.

Reading through the comments here I'm realizing that my single biggest error may have been the use of the word "Universal" :-D When you consider the spec as a "basis for agreement" between distributed application authors and not a unified theory of messaging - then the spec becomes a lot clearer.

The spec describes a message format and isn't intended to be a formal Internet RFC. As such, the thought was to leave definitions up to users rather than dictate things like priority ranges.

Thanks for this. The need for canonical JSON is perhaps the best reason for dropping the signature field from future versions of the spec. However, because only the `to` `from` and `body` fields are required there's no need avoid the format - just don't use the signature field unless the body field contains a single field with serialized data. Certainly, that use would need to be clearly documented.

Again your point is valid and will likely result in the depreciation of the signature field.

Thanks for taking the time to offer feedback.

+1 for mission statement, use case.

The point about inconsistent formatting is that by aligning a team(s) on how a message is formatted groups can avoid the introduction of multiple message formats between distributed services.

It's true the body field does introduce inconsistency and that's left for the application developers to resolve. The envelope fields are intended to be used in queuing and routing situations.

I disagree with "The destination doesn't need to be in the message". What about the use case where a message is forwarded or moves through proxy services?

+1 for metadata being larger than the payload :-D - Can't debate that. The only required fields are 'to', 'from' and 'body' and the short form of UMF can be used. Still, we've encountered situations where that metadata is still larger than the payload. But that doesn't completely invalidate the presence of the envelope in a distributed application.

Thanks, I really appreciate the time you took to offer feedback!

In an earlier version of the docs I actually had the spec in the readme but felt the sheer size was enough to send folks running. Using the readme to describe the spec (which I realize needs work!) allowed for a clean separation.

I've always liked s-expressions, unfortunately, it hasn't caught on in the circles I travel.

Hahaha. My dude, it's a damn good thing I'm not applying for your startup! And a great thing that my current and past employers didn't think I should resign. So you know what? I'm going to keep up this charade for a bit longer. Besides, the pay is great! :-D

The conical issue with regards fields and signatures is definitely and without question a valid point and should probably be removed from the spec.

You raise good points. I'll definitely reconsider your feedback in future iterations!

Your point about a logging field is interesting, but the MID field could be used in an out of band error acknowledgment.

Protobuf is great - but what if you don't need or want it?

Thanks for taking the time to comment!

Ah Linus - enough said. The UMF spec wasn't intended to be a standards paper. You might be able to tell it isn't formatted as such. Based on the comments in this post - it has at the very least helped spark interesting feedback and debate.

Wow - I really ruffled some feathers with this post :-D As I scanned the feedback, I found myself agreeing with some, but not all, of the comments.

I actually found some of the direct attacks amusing and got a good laugh. That said, I'd like to thank everyone who took the time to comment. One of the goals of any specification should be to iterate the spec based on the valuable feedback of others. I'll definitely take this opportunity to do that.

Thanks again.