[TLS] RFC 4366 server name indication

Summary:- Sanity check sought when using a std server name indication type of host_name, for non classical internet 
environments. Do I use properly use host_name, or create a new indication type?

RC4366 specifes  that Server name indication allows one to indicate a virtual server name. host_name in the only std type.

So lets assume an "outer" TLS Connection exists between the parties C->S, where the client nic 
for TCP is in fact one or many vlans/pseudo-nics in client's bridge/stack. Lets say, the outer TLS Connection 
once negotiated also gets its own vlan#base1, with a psuedo-Mac address in the local stack. Perhaps that
MAC even participates in ARP & binds to a DNS record using DHCP.

For whatever reason, the server party decides to create an "inner" TLS Connection , as is its right. It thus 
issues an (Extended)  client hello etc transferring this over the application_data of the outer connection, using 
tunneling techniques using some encapsulation standard (ethernet.v2 say)

In terms of server name extension rules as I read them, the outer tunnel's protocol engine is now the 
"application", which gets to "interpret" the host_name sent in the client hello. 

Lets say the wireless stack is bridging/trunking at layer 2 various vlans, each if which are adjacent to
vlan#base1 with local ids {vlan#base1#1, vlan#base1#2, vlan#base1#3). 

Given the application ( i.e. the TLS-Connection-capable bridge behind vlan.base#1) interprets the name, am 
I being consistent with the proposal if I indicate values such as  "1.base1.vlan.wirelesslan.isp.com"?

_________________________________________________________________
Type your favorite song.  Get a customized station.  Try MSN Radio powered by Pandora.
http://radio.msn.com