|I decided it was about time to get clearification on this issue from the horses mouth, so asked Zugg about the whole < and > issue, this was my letter and his response:|
I'm really not sure what specific problem you are referring to here.
MXP is supposed to be compatible with normal MUD text. Thus, a normal MUD that sends < and > instead of < and > should be handled properly. Turning on MXP should not mark this as an error (remember, MXP is not strict HTML).
Replacing < and > with < and > is considered optional in MXP. Whenever MXP sees a possible tag, it checks to see what "mode" it is in. When in "Open" mode, regular MUD text is expected that might include < and > characters. In "Open" mode, a tag is not allowed to span a line. So if it sees a possible tag and doesn't see the </tag> closing statement, then it assumes that the original tag was normal MUD text and the text is preserved.
It's only when in "Secure" mode that MXP is picky about invalid tags. When in Secure mode, an unrecognized tag is stripped, just like browsers do for HTML tags that they don't recognize.
So, in normal "Open" mode, no conversion of < and > is necessary. In fact, since Open mode is supposed to be the same as the normal MUD text for other MUD clients, such conversion would be annoying for the MUD coders.
I think this is mentioned in the MXP spec, but if you can point me to the specific section that you think is confusing, let me know and I'll take a closer look.
From: Patrick Elliott [mailto:...........@hotmail.com]
Sent: Sunday, January 15, 2006 11:37 AM
Subject: MXP specification issue
Name: Patrick Elliott
While I can understand how it might be an advantage for you to not do so, since your client isn't at all effected, it might be useful to ammend the MXP spec to clearify the "correct" behaviour when handling invalid tags. The specification, as it stands, implies that any case of failing to replace < and > with < and > in normal text should be an error. A client following this literally could either a) let invalid information pass through to the player anyway as normal text, or b) interpret the specification literally and remove the offending invalid tag, while generating a call to an optional error handler. The problem is, without a formal statement about which behaviour is correct, one could assume that its zMud that is failing to follow your own specification and that dozens of muds out there are screw this up, as a result of using your client to test their complience. The specification itself says nothing about how this should be correctly handled. It would be nice! if everyone had a notation from you as to how to deal with such a mistake.
Personally, I think your client, by not making the error obvious, is invalidating its own specification in this case, but that's just my impression. Unfortunately, if true, then maybe 80% of the muds out there are not only not following it correctly, they refuse to listen when someone points out that they are not following it correctly. I.e., because it works anyway, they don't feel the need to do the correct replacements.