Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ MUSHclient ➜ General ➜ MXP Spec clarification
MXP Spec clarification

Posting of new messages is disabled at present.

Refresh page

Pages: 1 2  3  

Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Mon 16 Jan 2006 06:20 PM (UTC)

Amended on Mon 16 Jan 2006 06:23 PM (UTC) by Shadowfyr

Message
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:

Quote:
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 &lt and &gt should be handled properly. Turning on MXP should not mark this as an error (remember, MXP is not strict HTML).

Replacing < and > with &lt and &gt 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.

Zugg

-----Original Message-----
From: Patrick Elliott [mailto:...........@hotmail.com]
Sent: Sunday, January 15, 2006 11:37 AM
To: support@zuggsoft.com
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 &lt and &gt 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.
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #1 on Mon 16 Jan 2006 07:18 PM (UTC)

Amended on Mon 16 Jan 2006 07:24 PM (UTC) by Nick Gammon

Message
Quote:

Zugg: Replacing < and > with &lt and &gt is considered optional in MXP.


I refer to the MXP spec by Zugg at:


http://www.zuggsoft.com/zmud/mxp.htm

"Since a normal < symbol is interpreted as the start of an element tag, you must use &lt; to refer to a less-than symbol directly."


That says "must use" not "can optionally use if the mode is open". I coded from that spec.


Quote:

When in "Open" mode, regular MUD text is expected that might include < and > characters. ... 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.


There is simply no reference to this in the spec, and in any case it doesn't make sense. First, what the spec says about "open" mode:


"In particular, if the tag element is Open, the user can change the color, gag, or redirect the tagged line. This is useful for various chat channels on the MUD.
...
When the mode is changed from OPEN mode to any other mode, any unclosed OPEN tags (tags that were used while in open mode) are automatically closed."


First, the purpose of open mode is simply to allow the user to insert things like <b> into chat text. The spec makes this clear.

Second, the spec makes clear that tags in open mode are automatically closed, if necessary.

For example, a player might chat:


<b>Hi there


According to the spec, this is allowed, the player can chat in bold, and he doesn't have to close the tag. The client will close it for him, otherwise every other line would be in bold also.

Now, Zugg says that if the client does not see </b> it "assumes that the original tag was normal MUD text". This completely and utterly contradicts the spec.



Let's go back 5 years to when I was adding MXP to MUSHclient. I sent a series of emails to Zugg to clarify parts of the spec. His answer to this one makes very clear that you don't "look ahead" to see if you get </b> before processing <b>.


Date: 11 Jan 2001 10:00:02 AM
From: zugg@zuggsoft.com
Subject: RE: MXP protocol - 2


Nick:

When do you start parsing for MXP tags? Once a newline has arrived? I ask because of the question we had yesterday about when triggers are evaluated. It is the same basic problem. If you parse when the TCP packet ends you may be half-way through a tag.


Zugg:

*** No, you parse MXP just like you parse ANSI color. You parse it right away. So, as soon as you see <B> you switch to bold font without waiting for the </B>. Then, at the newline, you close any OPEN tags that are still active. And yes, your TCP packet might end in the middle of a tag, just like it might end in the middle of an ANSI color sequence, so you have to plan for that and handle it.


The answer above makes it clear that <B> is converted to bold, regardless of what follows. I stand by the behaviour of MUSHclient 100%.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #2 on Mon 16 Jan 2006 08:32 PM (UTC)
Message
The email I posted is "from" Zugg. Yes, <b> would be considered a tag, <yadda, yadda!> is treated as text, according to him. Your correspondence only refers to a "valid" tag, not one that isn't recognized, so it hardly applicable to what happens when its not recognized. I sent another message to him in reply pointing out that the spec doesn't in fact make this clear and needs to be fixed. His email said basically, "I think it already says this", which it doesn't.

Point being, you are following the specification, but the specification is incomplete with respect to the correct behaviour. That is what I wanted to find out, since the issue keeps cropping up.
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #3 on Mon 16 Jan 2006 09:26 PM (UTC)
Message
Quote:

The email I posted is "from" Zugg.


I understand that.

Quote:

Your correspondence only refers to a "valid" tag, not one that isn't recognized, ...


True. However if < is not being converted then I am taking the fairly likely case that something like this will occur:


Obvious exits: <I>nn <B>lacksmith <U>ndertaker


Now if < is not being converted then we have the issue of how this line will look. It will be rendered by the client (perfectly validly) as:


Obvious exits: nn lacksmith ndertaker


Sure, we can catch things like <O> and render them as <O>, however you have shifted the problem to "all exits look strange" to "some exits look strange" which I don't think is a big improvement, do you?

You, or I, could write a small plugin. It would do OnPluginPacketReceived and scan the line for <x>, then if "x" isn't a valid MXP tag replace it by &lt;x&gt; (if MXP is active). As I said, that would fix *some* tags.

The spec says "you must use &lt; to refer to a less-than symbol directly" (my emphasis). No wriggle-room there. You *must* do it. If the server does not do it, it is not following the spec and is wrong.

The client cannot detect the different between:


Exits: <I>nn

You say <I>hi there


How can it? The fix is not a client-side fix. Sorry.


- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #4 on Mon 16 Jan 2006 09:37 PM (UTC)

Amended on Mon 16 Jan 2006 09:54 PM (UTC) by Nick Gammon

Message
Quote:

... the specification is incomplete with respect to the correct behaviour ...


OK, look at this correspondence in 2001 between Zugg and me:


My email to Zugg


-----Original Message-----
From: Nick Gammon
Sent: Sunday, June 03, 2001 9:04 PM
To: Zugg
Subject: Two important changes :)


Hi Zugg,

Two important changes to zMUD which I think are essential to make it and MUSHclient reasonably similar in their handling of MXP, even if you don't change anything else ... :)

1. Make it ignore any unrecognised tags rather than display them. This gives us both the chance to cope with new tags in the future without having to release our updated clients on the same day and try to get every player to install it, both of which are probably impossible tasks.

eg. tag <blah> if <blah> is not recogised, silently discard it (and, of course </blah> )

...




Zugg's reply


From: zugg@zuggsoft.com
Sent: 4 Jun 2001 01:16:40 PM
To: Nick Gammon
Subject: RE: Two important changes :)


Hi Nick,

Yes, I agree with (1). This is what made HTML powerful and extensible.

However, in the example:

<BLAH>Test</BLAH>

The "Test" text should still be displayed I think. That is what HTML does.

...



You can't get much clearer than that. Zugg agrees that clients should ignore non-recognised tags, which is what MUSHclient does.

MUSHclient does exactly what Zugg says it should do, display "Test" but not <BLAH> or </BLAH>.

Now, time to stop arguing over the spec and get the server developers to fix their bugs.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #5 on Mon 16 Jan 2006 09:52 PM (UTC)

Amended on Mon 16 Jan 2006 09:55 PM (UTC) by Nick Gammon

Message
Double post? Click the Refresh Page icon to redisplay the page. Refreshing might resend your last message.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #6 on Tue 17 Jan 2006 10:09 PM (UTC)
Message
Sigh.. Your going to hate this Nick, but the most recent response from Zugg follows:

Quote:
Well, as you mentioned with the spec, the email with Nick wasn't
specific about the "mode". What we are talking about to ignore
unrecognised tags is only in Secure mode.

As I mentioned, MXP Open mode is supposed to be compatible with normal
MUD output. In other words, a MUD without MXP support should still
display properly in a MXP-enabled client (in Open mode). So, in Open
mode, text from the MUD like:

<BLAH>Test</BLAH>

Would be displayed without any change (assuming <BLAH> is an undefined
tag). Only in Secure mode is this stripped to just "Test" without the
tags.

Anyway, I think you might have taken the email to Nick out of context.
It's been a long time, but I'm pretty sure we were talking about secure
mode in that email. Otherwise you lose compatibility between
MXP-enabled clients and non-MXP MUDs, which would be very bad. This is
the main reason for the Open vs Secure distinction in the first place.
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #7 on Wed 18 Jan 2006 02:14 AM (UTC)
Message
I have taken the discussion to his forum. :)

Effectively the response is that, for zMUD, MXP is always on. Full stop.

Thus, from zMUD's point of view, it must always attempt to display tags (like <O>ut) because it is always parsing MXP, and the MUD may simply not be MXP-enabled.

Personally I think it is a little strange to try to parse MXP from a non-MXP MUD, but there you are.

What zMUD does, is start up, with MXP enabled, and in "open" mode. Thus it is allowing the normal formatting tags (like <B> for bold).

I have asked how it handles:


Exits: <B>lacksmith


I haven't got a response yet, but to me this is the key question.

I am expecting the response "don't process it unless you get </B>", however this violates the spec which says that tags are automatically closed, and thus the </B> is not required.

There *is* a middle ground, to make a MUD that complies with MUSHclient (and the spec) and zMUD, and that is to do what the spec says. That is, to always use &lt; for <, like the spec says to do. However I don't see - still - how this will work with non-MXP MUDs.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #8 on Wed 18 Jan 2006 10:15 PM (UTC)

Amended on Wed 18 Jan 2006 10:39 PM (UTC) by Shadowfyr

Message
Yes. That is I think the main issue. With zMud you can't turn it off (as far as I know). Personally I think he simply overlooked the details for how to handle the situation when writing the specification. But I am guessing that his intent was what he said in his recent emails, since he assumed it would be on at all times. This makes sense, since in general you don't make clients that arbitrarilly turn off a certain protocol, instead of determining what to do based on negotiations. Though usually you don't have them always on either. As you point out, there are cases where it doesn't work, but for 90% of cases it does.

For personal reasons, I like being able to use the Open tags as a player, even on muds that don't support MXP, but on the other hand, it might be better if MXP had to be manually enabled or negotiated to work in both cases, just for the purposes of general sanity, in spite of the fact that having it that way would annoy the hell out of me. ;) Though, if both clients worked the same, this would hardly matter, since Open codes wouldn't work for anyone on a normal mud anyway.

At least one person tried briefly to develop something called ZMP (Like we need another one, with MXP, MSP, MCP, etc.), which was supposed to fix this by using escape codes for everything and thus *fix* what he considered problems. In reality, the codes he suggested just caused implimentation problems (I hate to see what it would have done to unicode) and replaced <> tags with unreadable, but functionally identical, escape sequences. As far as I know, development on it died out.

---

BTW. Which thread on there? I don't see anything that looks like it on the forum anyplace.
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #9 on Wed 18 Jan 2006 11:10 PM (UTC)
Message
He has a developer section, I think you need to apply for it. I imagine he would approve your application as you have been having discussions with him about it.

As I posted on his forum, I simply don't see how you can have MXP always on. Here is an example conversation:


Player 1: How you you make bold text in an HTML page?
Player 2: You put <b> and </b> around the words in bold


Now if MXP is on, without the knowledge of the server, and without the client turning it on (or indeed, in zMUD's case being able to turn it off), then this conversation will be converted to (in part) bold text.

I don't see how you can have MXP on without some form of negotiation. It is not the same as normal output. You will always have borderline cases like people talking about <B> which will appear normal MXP.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #10 on Thu 19 Jan 2006 05:07 PM (UTC)

Amended on Thu 19 Jan 2006 05:09 PM (UTC) by Shadowfyr

Message
Yeah. I get the sense that he figured, "This is so rare a possibility, it hardly matters." And he is mostly right. I can think of only one case where it would be common, and that is it you telneted into a game like Tradewars 2000, which your client wouldn't work for anyway, since it uses *lots* of text positioning. His though, would be able to play it, except that all the command display menus are like:

<I> Ship Information
<N> Navigation
...

Ooops!

But except for a few diehards that played it in the BBS days, hardly anyone plays it anymore and muds generally don't do this. Its far more common for muds to have entire words or phrases, like <North>, or <The Plaza Fountain>. You example of <N>orth is unlikely, simply because all muds use similar code bases and usually N, S, E, W, etc. are aliases to the commands north, south, etc. It makes no sense for them to display the alias that way, as though it is the actual command. The number of times someone it likely to be discussing HTML on a channel or in tells is very small too. Yes, its a problem, but imho it is probably an extremely rare one, which is why Zugg, as far as I know, never had huge numbers of people complaining about the behaviour.

Frankly, I think the guy with ZMP had one thing right. His didn't cause these problems, but since the intent was to allow people with compatible clients to use things like color, even on non-MXP muds when talking to each other, ZMP also wouldn't work the way MXP was intended to. Its a catch-22. If its on only when asked for, you can't use it as intended for general players, but if on always, some unusual and rare situations will screw you up.
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #11 on Thu 19 Jan 2006 09:23 PM (UTC)
Message
Personally I don't like design where "it works most of the time", still there you are.

It is obvious that zMUD is not going to be changed, it is fundamental to the way it works. For example, in zMUD you can do something like "you see <b>trouble</b> ahead" in "send to output" in their triggers. In other words, parsing MXP is pervasive in the client.

In MUSHclient you would use ColourTell to achieve a similar result.

I have asked that - at the very least - he append a clarifying note (which I have written) to the MXP spec, to make it clear to server developers that the two clients behave in different ways, and to suggest coding in such a way that is compatible with both clients.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Samson   USA  (683 posts)  Bio
Date Reply #12 on Fri 20 Jan 2006 02:04 AM (UTC)
Message
All of this reminds me of IE vs Everyone Else when it comes to web standards and the resulting web developer hacks to deal with the discrepencies between IE and the standards. The thought of having to do client sniffing in a similar fashion to how browser sniffing is done is just silly. Follow the spec, and let the chips fall where they will.
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #13 on Fri 20 Jan 2006 07:43 AM (UTC)
Message
What can you do? I have commented at length on the zMUD forum about how the behaviour of zMUD does not comply with the spec.

Zugg said there today:

Quote:

As far as the MXP spec itself, I've *always* said that the spec needs work and can be improved. I just haven't had the time to do it myself.


In other words, the spec is wrong, and he hasn't had time to fix it. However the spec is all we have to go on, as the code to zMUD itself is not available.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Darwin   USA  (125 posts)  Bio
Date Reply #14 on Sat 08 Sep 2007 11:03 PM (UTC)
Message
Sorry to resurrect this thread, but a recent discussion about MXP on MudBytes brought this thread to my attention.

Within this thread, I've noticed it mentioned that zMUD has MXP always on. Having been using zMUD for close to, if not more than, 10 years, I can state that this is not so. As far as I can remember, there has always been an option to disable MXP parsing within the settings. I'm not certain if it has always been the case, but I am certain that as of the first post on this thread, dated the 16th of January 2006, that the option did exist to disable MXP within zMUD. That option has been there since at least version 5.55 which was released some time in the late '90s.

I've never played any MXP enhanced muds so I always had this option disabled. I did, however, notice that if it was enabled, that it sometimes caused my prompt to disappear because it did start with the less-than character "<".

However, with more recent versions, this no longer happens with MXP parsing turned on.

As for the MXP specs not being complete... There are some very talented programmers on this and other related forums, I doubt Zugg will mind if someone steps up and fixes the issues with MXP that are being addressed in this thread. Unless the issue isn't with the specs itself, but rather how the clients parse them.
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

90,169 views.

This is page 1, subject is 3 pages long: 1 2  3  [Next page]

Posting of new messages is disabled at present.

Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home