Avoid emphasis where not intended

diff --git a/design/tlv.mdwn b/design/tlv.mdwn
index ec1be93..58355ad 100644 (file)
--- a/design/tlv.mdwn
+++ b/design/tlv.mdwn
@@ -20,11 +20,11 @@ hartmans: OK, so there are two different usages.
 lukeh: as my understanding is we get the acceptor name back anyway in the EAP CB attributes  
 hartmans: 1) server name indication: the initiator knows the target name, but the acceptor may server multiple names.  
 hartmans: Here, the acceptor wants to know what name the initiator is calling.  
-***hartmans needs to think through the gss implications of what names the server accepts with Nico  
+\*\*\*hartmans needs to think through the gss implications of what names the server accepts with Nico  
 hartmans: The other usage is null target name: the initiator doesn't know the target name but will look at the target name in the established context and see if it likes it.  
 hartmans: However in our mechanism, the initiator needs to learn the target name early so it can channel bind to it in EAP so it actually can believe the result.  
 hartmans: No, we don't get the acceptor name back in the eap CB.  
-hartmans: We *send* it in the eap cb and get back an indication about whether the server considered it in the CB result.  
+hartmans: We \*send\* it in the eap cb and get back an indication about whether the server considered it in the CB result.  
 lukeh: ah.  
 hartmans: We don't get the value back.  
 hartmans: The other thing I'm wondering.  
@@ -60,7 +60,7 @@ hartmans: Sadly, Jari is not online. (He's the obvious eap expert in my buddy li
 Josh: I think we have previously floated the idea of using that data field for federation selection  
 lukeh: heh, can we shove the acceptor name in there  
 hartmans: Josh, I think that the changes we're talking about for target name null and for sni will give us the rope we need for federation selection.  
-***hartmans will investigate what that's useful for.  
+\*\*\*hartmans will investigate what that's useful for.  
 lukeh: please define SNI  
 lukeh: server name indication  
 lukeh: ?  
@@ -75,7 +75,7 @@ lukeh: there are still a few too many special cases to be completely in love wit
 lukeh: but hopefully after a few more days of hacking it will get there  
 lukeh: I've added some debug tokens in the initial leg to test that that works  
 lukeh: the previous extension tokens (GSS CB, reauth) are now just, obviously, TLVs in the last leg  
-lukeh: there is now only one *GSS* token for context establishment, TOK_TYPE_ESTABLISH_CONTEXT  
+lukeh: there is now only one \*GSS\* token for context establishment, TOK_TYPE_ESTABLISH_CONTEXT  
 lukeh: and a bunch of "inner" token types  
 lukeh: #define ITOK_TYPE_CONTEXT_ERR           0x00000001  
     #define ITOK_TYPE_ACCEPTOR_NAME_REQ     0x00000002  
@@ -88,7 +88,7 @@ lukeh: #define ITOK_TYPE_CONTEXT_ERR           0x00000001
     #define ITOK_TYPE_REAUTH_RESP           0x00000009  
     #define ITOK_TYPE_VERSION_INFO          0x0000000A  
     #define ITOK_TYPE_VENDOR_INFO           0x0000000B  
-    #define ITOK_FLAG_CRITICAL              0x80000000  /* critical, wire flag */  
+    #define ITOK_FLAG_CRITICAL              0x80000000  /\* critical, wire flag \*/  
   
 lukeh: s/last leg/last round trip/  
 hartmans: What do you mean by token types in the table?  
@@ -138,7 +138,7 @@ lukeh: note: the states are bitmasks.
 lukeh: there's some verbose commenting in init_sm.c too.  
 hartmans: Ah, that makes so much more sense from the table  
 hartmans: This is quite clever.  
-lukeh: Hmm, it still doesn't feel *quite* right. Too many exceptions. I suspect if that if I was doing it from scratch rather than refactoring it might look different. But, it seems to work for now. Will revise over coming days.  
+lukeh: Hmm, it still doesn't feel \*quite\* right. Too many exceptions. I suspect if that if I was doing it from scratch rather than refactoring it might look different. But, it seems to work for now. Will revise over coming days.  
 lukeh: I think it is ugly because it collapses the state and token dimensions into a single one.  
 lukeh: However it does make it easier to have tokens that support multiple states.  
 lukeh: Although there are some limitations with that (the dispatch table is not retraversed after a state change so it effectively only works for exception tokens; of course, that's easily fixed)  
@@ -153,7 +153,7 @@ lukeh: yes, I guess we do, what else could one do?
 lukeh: it's a black box  
 lukeh: I don't know what happens yet if the EAP machine emits a token on success, I don't think that's possible though  
 lukeh: I need to check  
-***hartmans has too much of a relational database mindset to think of that as more than an efficiency issue  
+\*\*\*hartmans has too much of a relational database mindset to think of that as more than an efficiency issue  
 lukeh: yeah, I never used relational databases, so I never had that mindset  
 hartmans: I think depending on EAP to be consistent is fine.  
 hartmans: We could actually echo the eap state in some sort of market token. That would be far far worse.