TinTin++ Mud Client The TinTin++ message board

 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
TinTin++ Mud Client

MTTS concerns

 
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> General Discussion
View previous topic :: View next topic  
Author Message
Slysven



Joined: 10 Apr 2011
Posts: 375
Location: As "Jomin al'Bara" in WoTMUD or Wiltshire, UK

PostPosted: Sat Mar 10, 2018 12:26 am    Post subject: MTTS concerns Reply with quote

I do like the idea of MTTS which is a MUD related supplement to the Telnet sub-option 24 TYPE (Terminal Type) - that is described in RFC1091. However (and I am getting a feeling of Deja Vu here but I cannot find this mentioned elsewhere on these forums) there are some things that I have issues with:

  • The existing MTTS specification does not encourage the provision of client version data:
    which can compromise the ability of a MUD Server to work around deficits in older version of known developing clients. I see that:
    In the MTTS specification it was wrote:
    On the first TTYPE SEND request the client should return its name, preferably without a version number and in all caps.

    but:
    In RFC1091 page 3 it was wrote:
    In some cases, either a particular terminal may be known by more than one name, for example a specific type and a more generic type, or the client may be a workstation with integrated display capable of emulating more than one kind of terminal. In such cases, the sender of the TERMINAL-TYPE IS command should reply to successive TERMINAL-TYPE SEND commands with the various names. In this way, a telnet server that does not understand the first response can prompt for alternatives. If different terminal emulations are supported by the client, the mode of the emulator must be changed to match the last type sent, unless the particular emulation has other Telnet options (e.g., BINARY) as prerequisites (in which case, the emulation will switch to the last type sent when the prerequisite is fulfilled). When types are synonyms, they should be sent in order from most to least specific.

    {My added emphasis}

    This is the reason why, it is not, in my humble opinion the right choice and if/when I add MTTS to the client I am coding I propose this alternative, that the client will return its name up to three times in decreasing order of specificity:
    • with a version (see next item) and a patch level (for the Client I am coding on the development versions will have a `-DEV`suffix, there may be other texts for versions that are testing/debugging new code for a Server operator who is working with us) - In all cases the total TTYPE string must be composed of no more than 40 "NVT ASCII" characters to comply with RFC1091 limits.
    • with just a semantic version number (of the form -<major integer>.<minor integer>.<revision integer>)
    • Just the the client name on its own


  • The individual capabilities denoted for MTTS could do with clarification, specifically:
    • Quote:
      "ANSI" Terminal supports the common ANSI color codes. Supporting blink and underline is optional.


      There is an awful lot of ANSI codes - hell, there is even a lot of SGR codes but to be meaningful to MUD Servers encountering unknown Clients there really needs to be a minimum set specified for both parties to know - for Clients so that they know the bare minimum they must provide and for Servers so that they know the maximum they can only utilise unless they know better from identification of the Client from earlier responses. Technically, if the Server cycles to the, repeated, last entry in the list (i.e. the MTTS) and does not then proceed to make a further sub-option request to get the Client to wrap-around back to the first setting then the master document, the RFC would imply that the client must then only operate in the possibly limited mode of just those known features and the Server must not make use of other extra ones it knows about for a Known client!

      For the minimum set of ANSI SGR features would the following be suitable:
      Code:
      0    Reset    Set color and display state to default
      1    Bold    Set color intensity to bold
      3    Italic    Display text as italic
      4    Underline    Display text as underline
      22    Bold: off    Set color intensity to default
      23    Italic: off    
      24    Underline: off    Neither single or double
      30    Foreground: black    
      31    Foreground: red    
      32    Foreground: green    
      33    Foreground: yellow    Faint yellow often looks brown
      34    Foreground: blue    
      35    Foreground: magenta    
      36    Foreground: cyan    
      37    Foreground: white    
      39    Foreground: reset    Reset foreground color to default
      40    Background: black    
      41    Background: red    
      42    Background: green    
      43    Background: yellow    
      44    Background: blue    
      45    Background: magenta    
      46    Background: cyan    
      47    Background: white    
      49    Background: reset    Reset backround color to default


    • Quote:
      "VT100" Terminal supports most VT100 codes, including ANSI color codes.


      "VT100" has little to nothing to do with colour codes - in fact non of the VT100 range of DEC terminals supports colour in any way (except that the phosphor could be a long persistence green or orange! ) - colour was only introduced in the later VT241 and there is a hint of a suggestion in the Wikipedia pages that it did not work via SGR codes anyhow. Perhaps you meant to say Terminal supports a minimum set of VT100 codes {which ones} and the ANSI SGR codes mentioned under that item?


  • In the MTTS specification it was wrote:
    The client should never initiate a negotiation, in the case this does happen the server should abide by the state change. To avoid trigger loops the server should not respond to negotiations from the client, unless it correctly implements the Q method in RFC 1143.


    This seems a little unclear to me, is it permissible for the Client to tell the Server that it has changed it capabilities by sending an IAC WONT TTYPE, to wait for a IAC DONT TTYPE acknowledgement and then send a IAC WILL TTYPE and then wait for the Server to investigate the changed Client capabilities?

    For instance, my client does now support UTF-8 encoding - but it will also support a range of single byte ISO 8895 and other encodings as well as GBK one/two byte and GB18030 one/two/four byte ones - and as this is via a user setting, it can change mid-stream although that is not recommended (unless it is synchronised to a multi encoding capable MUD server - they do exist). Similarly for the Screen Reader indication - although a totally blind user may be using that 100% of the time, a partially sighted or even fully sighted user who just wants their MUD experience to be more audible may turn such an option on and off during a MUDding session. So how can MTTS handle such changes gracefully, I believe it has to allow a client to signal that the indication has changed - and demanding that the Client completely disconnects and reconnects to do so is not an end-user friendly option!


N.B. The client I am coding for does not currently support the OSC option to allow the Server to define the basic 16 colours but it is something that could feasible be implemented - if so though it would be something that we would give our client control over the permission to allow the Server to do so. That being the case is that feature something that could be a separate new bit in the MTTS capabilities?
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3844

PostPosted: Sat Mar 10, 2018 9:52 pm    Post subject: Re: MTTS concerns Reply with quote

Slysven wrote:

This is the reason why, it is not, in my humble opinion the right choice and if/when I add MTTS to the client I am coding I propose this alternative, that the client will return its name up to three times in decreasing order of specificity:

MTTS doesn't forbid reporting version numbers. So reporting client + version + level is fine. Not reporting MTTS on the 3rd request would violate protocol and might break support for some servers.

Slysven wrote:

[list][*] "ANSI" Terminal supports the common ANSI color codes. Supporting blink and underline is optional.

There is an awful lot of ANSI codes - hell, there is even a lot of SGR codes but to be meaningful to MUD Servers encountering unknown Clients there really needs to be a minimum set specified for both parties to know

The 'common' ANSI color codes are 0, 1, 30-37. It's what most MUD servers use. More is better of course for the client, but I have no control over that. The specification links to a fairly complete list of SGR codes.

Slysven wrote:

[*]
Quote:
"VT100" Terminal supports most VT100 codes, including ANSI color codes.


"VT100" has little to nothing to do with colour codes

That's why it specifies that VT100 support should also include color support. As implementing VT100 is far more difficult than implementing color I don't think that'll be a problem.

Slysven wrote:

This seems a little unclear to me, is it permissible for the Client to tell the Server that it has changed it capabilities by sending an IAC WONT TTYPE, to wait for a IAC DONT TTYPE acknowledgement and then send a IAC WILL TTYPE and then wait for the Server to investigate the changed Client capabilities?

I think most MUDs will only use MTTS during character login and creation. If you really want to you could send a TTYPE MTTS <bitvector> update, which is technically allowed, and the server is supposed to abide by it and not respond.

Slysven wrote:

N.B. The client I am coding for does not currently support the OSC option to allow the Server to define the basic 16 colours but it is something that could feasible be implemented - if so though it would be something that we would give our client control over the permission to allow the Server to do so. That being the case is that feature something that could be a separate new bit in the MTTS capabilities?

The server has the power to disconnect the client, so I think you worry about giving the server a little power of the client while it already has tremendous power. You could however implement OSC in such a way that it only affects the session the sequence is send to.

In TinTin++ it will impact all sessions so OSC could be pretty annoying, but I've never heard of a server abusing escape codes.
Back to top
View user's profile Send private message Send e-mail
Slysven



Joined: 10 Apr 2011
Posts: 375
Location: As "Jomin al'Bara" in WoTMUD or Wiltshire, UK

PostPosted: Sun Mar 11, 2018 7:46 pm    Post subject: Re: MTTS concerns Reply with quote

Scandum wrote:
Slysven wrote:

This is the reason why, it is not, in my humble opinion the right choice and if/when I add MTTS to the client I am coding I propose this alternative, that the client will return its name up to three times in decreasing order of specificity:

MTTS doesn't forbid reporting version numbers. So reporting client + version + level is fine. Not reporting MTTS on the 3rd request would violate protocol and might break support for some servers.

That was what worried me about the specification, the TTYPE RFC does not specify a specific number of responses only that one that was identical to the previous one marks the end of the list and that for MTTS it must be the last/repeated one. So the, currently hypothetical one on my Client - lets say it is called MudClient response in order could be:
  • MUDCLIENT-3_5_1-TESTING_BUGFIX_42
  • MUDCLIENT-3/5/1
  • MUDCLIENT
  • ANSI-256COLOR
  • MTTS9 {Based on +1 (for ANSI) +8 (for 256-colors) Client supports SCR[34]8;5;<0-255>...m codes}
  • MTTS9 {repeated to indicate end of TTYPE sub-options}


A further request would reset to send the first in the list again. Note that the MTTS for this client currently could be with an additional +4 (for UTF-8) if it is set for a MUD Server encoding of UTF-8 (it is by default but it can be changed easily enough. I can see that further developments could also add +64(for Screen Reader available and enabled) - the Qt libraries this GUI client uses has now got a workable TTS system available and we are working to incorporate access to it and interested parties are talking about modifications to make the Client more VI-user friendly. Also I see that my previous query about OSC is already encoded as +32 (for OSC OSCPnrrggbb and OSCR codes) so that would be added in if the user has enabled it and it is my intention to add the +256 (for TRUECOLOR Client supports SCR[34]8;2;<0-255>;<0-255>;<0-255>...m codes).

Scandum wrote:
Slysven wrote:

[list][*] "ANSI" Terminal supports the common ANSI color codes. Supporting blink and underline is optional.

There is an awful lot of ANSI codes - hell, there is even a lot of SGR codes but to be meaningful to MUD Servers encountering unknown Clients there really needs to be a minimum set specified for both parties to know

The 'common' ANSI color codes are 0, 1, 30-37. It's what most MUD servers use. More is better of course for the client, but I have no control over that. The specification links to a fairly complete list of SGR codes.

Okay, that is an even smaller subset than I gave but within the capabilities of the Client I am coding on.

Scandum wrote:
Slysven wrote:

Quote:
"VT100" Terminal supports most VT100 codes, including ANSI color codes.


"VT100" has little to nothing to do with colour codes

That's why it specifies that VT100 support should also include color support. As implementing VT100 is far more difficult than implementing color I don't think that'll be a problem.

Ah, I think there was a phrasing/semantics issue there - the use of including in that sentence implies to English speakers that ANSI color codes are a sub-set of the VT100 codes - it would not do that if it was instead: "Terminal supports most VT100 codes, it also includes the common ANSI color codes." On the other hand, as MTTS is a bitwise encoding it is confusing to include the "common ANSI color codes" here as well as in their own separate bit.

Scandum wrote:
Slysven wrote:

This seems a little unclear to me, is it permissible for the Client to tell the Server that it has changed it capabilities by sending an IAC WONT TTYPE, to wait for a IAC DONT TTYPE acknowledgement and then send a IAC WILL TTYPE and then wait for the Server to investigate the changed Client capabilities?

I think most MUDs will only use MTTS during character login and creation. If you really want to you could send a TTYPE MTTS <bitvector> update, which is technically allowed, and the server is supposed to abide by it and not respond.

I do not think it works like that:
In RFC1091 page 2 section 5 it was wrote:
Once the two hosts have exchanged a WILL and a DO, the sender of the DO TERMINAL-TYPE (the server) is free to request type information. Only the server may send requests (IAC SB TERMINAL-TYPE SEND IAC SE) and only the client may transmit actual type information (within an IAC SB TERMINAL-TYPE IS ... IAC SE command). Terminal type information may not be sent spontaneously, but only in response to a request.

This contradicts what you are saying I think, however, later on
In RFC1091 bottom of page 3 section 7 it was wrote:
7. User Interfaces

Telnet clients and servers conforming to this specification should provide the following functions in their user interfaces:

Clients supporting multiple emulation modes should allow the user to specify which of the modes is preferred (which name is sent first), prior to connection establishment. The order of the names sent cannot be changed after the negotiation has begun. This initial mode will also become the default with servers which do not support TERMINAL TYPE.

Servers should store the current terminal type name and the list of available names in a manner such that they are accessible to both the user (via a keyboard command) and any applications which need the information. In addition, there should be a corresponding mechanism to request a change of terminal types, by initiating a series of SEND/IS sub-negotiations.

Note that last sentence, it seems to me that the only way that the client can change the TTYPE is to initiate the Server to restart the process which means switching it off and on again and letting the Server discover a changed MTTS value...

Scandum wrote:
Slysven wrote:
N.B. The client I am coding for does not currently support the OSC option to allow the Server to define the basic 16 colours but it is something that could feasible be implemented - if so though it would be something that we would give our client control over the permission to allow the Server to do so. That being the case is that feature something that could be a separate new bit in the MTTS capabilities?

The server has the power to disconnect the client, so I think you worry about giving the server a little power of the client while it already has tremendous power. You could however implement OSC in such a way that it only affects the session the sequence is send to.

In TinTin++ it will impact all sessions so OSC could be pretty annoying, but I've never heard of a server abusing escape codes.

I had missed the OSC option as one bit already in the MTTS values so I was worrying about something that isn't an issue (provided I report something via MTTS that matches the user setting of "Allow the Server to adjust the basic ANSI 16 colour setting. In the client I am coding on it can support multiple sessions with different settings - even to the same MUD Server (BTW does that make it a proxy within the meaning of MTTS +128 value)?

One thing that I have found that may be an issue for both the MTTS and my client's existing TTYPE (it just reports Mudclient 3.x.y-build repeatedly at the moment) is that RFC1010 (page 28) describes what the content of the TTYPE string should be, it says:
In RFC1010 it was wrote:
A terminal names may be up to 40 characters taken from the set of uppercase letters, digits, and the two punctuation characters hyphen and slash. It must start with a letter, and end with a letter or digit.

So, there cannot be spaces (which I know there is one in my client's value) and you seem to have between the MTTS and the numeric value for and for TinTin++ it cannot have the ++ so I guess you ought to change it TINTIN-PLUS-PLUS... Smirk


Last edited by Slysven on Sun Mar 11, 2018 10:08 pm; edited 1 time in total
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3844

PostPosted: Sun Mar 11, 2018 9:45 pm    Post subject: Re: MTTS concerns Reply with quote

Slysven wrote:
So the, currently hypothetical one on my Client - lets say it is called MudClient response in order could be:
  • MUDCLIENT-3_5_1-TESTING_BUGFIX_42
  • MUDCLIENT-3_5_1
  • MUDCLIENT
  • ANSI-256COLOR
  • MTTS9 {Based on +1 (for ANSI) +8 (for 256-colors) Client supports SCR[34]8;5;<0-255>...m codes}
  • MTTS9 {repeated to indicate end of TTYPE sub-options}


That would be incompatible with the specification which states the client should report the terminal type on the 2nd request.

Slysven wrote:

Ah, I think there was a phrasing/semantics issue there - the use of including in that sentence implies to English speakers that ANSI color codes are a sub-set of the VT100 codes - it would not do that if it was instead: "Terminal supports most VT100 codes, it also includes the common ANSI color codes." On the other hand, as MTTS is a bitwise encoding it is confusing to include the "common ANSI color codes" here as well as in their own separate bit.

It's indeed a bit ambiguous. The suggestion to report ANSI as a terminal type is for muds that cycle looking for known terminal types that do not support mtts.

Slysven wrote:

Terminal type information may not be sent spontaneously, but only in response to a request.

Then I guess there's no way to update the information. MTTS however kind of allows it.

Slysven wrote:

In the client I am coding on it can support multiple sessions with different settings - even to the same MUD Server (BTW does that make it a proxy within the meaning of MTTS +128 value)?

TMC's web client would be considered a proxy.

Slysven wrote:

So, there cannot be spaces (which I know there is one in my client's value) and you seem to have between the MTTS and the numeric value for and for TinTin++ it cannot have the ++ so I guess you ought to change it TINTIN_PLUS_PLUS... Smirk

This is one of those cases where we simply ignore silly rules made up by a bunch of nerds 30 years ago. Coffee
Back to top
View user's profile Send private message Send e-mail
Slysven



Joined: 10 Apr 2011
Posts: 375
Location: As "Jomin al'Bara" in WoTMUD or Wiltshire, UK

PostPosted: Sun Mar 11, 2018 11:04 pm    Post subject: Reply with quote

I've just spotted that the two punctuation characters are - and / only and not _ so it is even uglier than I thought Crying.

You posted your reply before I refreshed my browser so my incomplete edit to swap out the '.''s didn't get in before hand. Nope

That restriction on the characters is not so silly when you consider another part of RFC1091:
Quote:
6. Implementation Issues

The "terminal type" information may be any NVT ASCII string meaningful to both ends of the negotiation. The list of terminal type names in "Assigned Numbers" is intended to minimize confusion caused by alternative "spellings" of the terminal type. For example,
confusion would arise if one party were to call a terminal "IBM3278-2" while the other called it "IBM-3278/2". There is no negative acknowledgement for a terminal type that is not understood, but certain other options (such as switching to BINARY mode) may be refused if a valid terminal type name has not been specified.

In some cases, either a particular terminal may be known by more than one name, for example a specific type and a more generic type, or the client may be a workstation with integrated display capable of emulating more than one kind of terminal. In such cases, the sender of the TERMINAL-TYPE IS command should reply to successive TERMINAL-TYPE SEND commands with the various names. In this way, a telnet server that does not understand the first response can prompt for alternatives. If different terminal emulations are supported by the client, the mode of the emulator must be changed to match the last type sent, unless the particular emulation has other Telnet options (e.g., BINARY) as prerequisites (in which case, the emulation will switch to the last type sent when the prerequisite is fulfilled). When types are synonyms, they should be sent in order from most to least specific.

I think we both agree that the string should be handled case insensitively - which reduces one scope for confounding things - so using UPPER CASE makes sense.
Taking a wider view I can see that the current implementation of MTTS is trying to simplify the client identification by only allowing one synonym for the specific client to be sent; but I still think that it is flawed in not permitting more specific details to be sent first in a manner that does follow the spirit of the RFC - like wot I sed.

I believe there are Servers that have taken steps to try and determine my Client's version to work around bugs in earlier versions which is not going to be as simple to implement if it cannot be passed this way. I suppose there are other Out Of Band protocol through which the client version can be passed to the Server ATCP/GMCP include it in the initial "Hello". If MTTS is ever revised I would hope that it could be expanded to allow the more detailed client identifiers to be sent but the current interpretation does disappoint me. Sad

Scandum wrote:
Slysven wrote:
...
Terminal type information may not be sent spontaneously, but only in response to a request.
...

Then I guess there's no way to update the information. MTTS however kind of allows it.
Sending a IAC SB TTYPE IS "MTTS<new value>" IAC SE without receiving a IAC SB TTYPE SEND IAC SE first is what this is saying isn't it? Confused I thought that sending IAC WONT TYPE, waiting for IAC DONT TYPE and then IAC WILL TYPE and hoping the Server will recognise it as the Client trying to tell it a MTTS setting has changed and then re-negotiate to determine the new setting sounds potentially do-able - are you saying that this is also prohibited {I have not entirely got my head around the Q-method in RFC1143)?
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3844

PostPosted: Mon Mar 12, 2018 6:15 pm    Post subject: Reply with quote

Slysven wrote:
If MTTS is ever revised I would hope that it could be expanded to allow the more detailed client identifiers to be sent but the current interpretation does disappoint me. Sad

Except that MTTS does allow sending the version number, it simply states a preference not to do so. If you want to provide the version that's perfectly fine.

I'll update the specification to simply state that adding a version number is optional, and leave it entirely up to the client developers.

Scandum wrote:
are you saying that this is also prohibited {I have not entirely got my head around the Q-method in RFC1143)?

It's not prohibited, but it probably won't work with most servers.

MTTS is mainly informative and not intended as a configuration. Just because someone uses a client that is capable of color doesn't mean they want to see color, some people prefer black and white.

So ultimately I don't think this is something you should be worried about.
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> General Discussion All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads
TinTin++ Homepage

Powered by phpBB © 2001, 2002 phpBB Group