I just browsed the text and the code today, read it as you first came up with it a couple of month ago. It's quite difficult to keep every detail in mind. I never had the need to code things concerning your proposal, so I can only find conceptual oddities like the 64+1 name length.

Of course I appreciate your comments. I wish more people would "criticize" the document so I can improve it.

Podatron, remember that I have something obsonete for lend you at the euskalparty

That's exactly the reason why I posted my comments. But the topic seems to be very strange to most of the people here, including me, so you'll get only few reactions. To my mind, you're going the right way, i.e. making a very formal proposal on a topic with future relevance waiting for reactions and corrections, but to most of the users here, its much too formal and too professional to really care about it. (Remember that we're hobbyists!) This very way you provide your proposal don't let me expect to have such conceputal oddities in it. As I first read your text month ago, I felt that there was something I don't totally agree with, but I didn't realize what. After browsing it today, it came out clearly that's abaut this 64+1 thingy.

@NapalM: Yes, thank you, and now it's in less than two weeks
@Konamiman: Sorry, for beeing offtopic, but that's a good place here to reach you: Will you be on the Euskal this year again?

I also use stringlength not power of 2 in my programms, but these are in Pascal and hence easy to change and not MC.

I have published the code samples in the hope that it will help to better understand the whole thing. Apart from this, I don't know what else to do in order to clarify the exposed ideas. Any suggestion?

Prodatron: No, sorry, this time I can't go to Euskal party. Last year trip was sort of an exception.

Try to express your ideas in your own way, not with an RFC-style text behind it. Go out somewhere with just paper and pencil and rewrite it in your own words. Try to shorten it. The MC provided looks just fine, but who takes the effort to try to understand it if there's no need?

Hm, one comment out of the blue, without having a look at the spec
Why limit that string length to 63 (or 64 or 65 or 87.5 ) if you want to terminate the string with a 0-byte anyway?

Tanni: but that's already my style... I usually write documentation this way, only that this time I used a XML processor to generate the document with RFC look. If I try to shorten it, I will end up rewriting the "Sample scenario" section, I think.

AuroraMSX: limiting the string lengths helps developers at the time of allocating space for string mnipulation tasks. 63 chars is a good length for a short name, I think.

Ok, you win:

Introduction to the MSX-UNAPI specification (short!)

If this is still not easy to understand, I'll change my Turbo-R for a Vista-capable Spectrum!

Version 0.4 of the specification is ready.

Also, I have added a section for MSX-UNAPI in my web page, from where where all the published documents are easily reachable.

What's new compared to the previous ones?

Please look at the document version history at the end of the document itself. And remember to check out the introductory document, it is more human readable than the complete spec.

Oops, missed that Thanks. However, the history only goes up to version 0.2, I thought you said there's 0.4 now?