Return to mroe.idea0 CVS log

Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / others / X / ideas

Annotation of 43BSDReno/contrib/isode-beta/others/X/ideas/mroe.idea0, revision 1.1.1.1

1.1       root        1: (Message inbox:17)
                      2: Replied: Tue, 17 Oct 89 10:47:51 +0100
                      3: Replied: [email protected]
                      4: Received: from vs6.cs.ucl.ac.uk by pyr1.Cs.Ucl.AC.UK   via Ethernet with SMTP
                      5:            id aa02057; 16 Oct 89 18:44 GMT-0:00
                      6: To: Jon Crowcroft <[email protected]>
                      7: cc: [email protected]
                      8: Subject: Re: Moron X Window protocol on ISODE TS 
                      9: In-reply-to: Jon Crowcroft's message of Mon, 16 Oct 89 11:45:46 +0100.
                     10: Date: Mon, 16 Oct 89 18:42:41 +0100
                     11: From: Mike Roe <[email protected]>
                     12: Source-Info:  toast.cs.ucl.ac.uk
                     13: 
                     14: 
                     15: >  >2. (possibly related) addressing.
                     16: >  >X uses user friendly names for m/c:displays.#
                     17: >  >What would you advise i use as T-SAPs and does this go in one of the
                     18: >  >magic isoentities/isoservices files? - i need loadsa help on that part
                     19: >  >of the junk.
                     20: 
                     21: a. isoservices is only used for dynamic servers (those started by tsapd).
                     22: 
                     23: b. The choice of TSEL is vital only for dynamic servers (tsapd looks at it
                     24:    to decide what to exec). For a static server over RFC-1006 transport, the
                     25:    IP address will uniquely identify the server (choose whatever you like
                     26:    as a TSEL -- it can't clash with anything else). If
                     27:    you've got a real OSI TS in the kernel, though, the TSEL matters even for
                     28:    static servers. I'd use string selectors "X0", "X1" etc.
                     29: 
                     30: c. It sounds like you need an entry in isoentities for each display. Something
                     31:    like:
                     32: 
                     33:    vs1 xserver0  <random object identifier> "" "" "X0"
                     34:           TCP vs1 <port>
                     35: 
                     36:   BEWARE: The format may be different in ISODE 6.0.
                     37: 
                     38:   I don't know whether you'll need a separate port for each display or not.
                     39: 
                     40: > (*dah dah) Authentication
                     41: 
                     42: It looks like you should be using transport layer encryption here. (Rather
                     43: than presentation layer, as used by X.500 for example).
                     44: 
                     45: The big problem with T-layer encryption is how you exchange session keys:
                     46: I dont know of any agreed method for doing this. Also, the CR is probably
                     47: not big enough to hold an authenticator.
                     48: 
                     49: A thought has just occurred to me: 
                     50: **** Session layer encryption ****
                     51: 
                     52: The security architecture (ISO 7498-2-1988(E)) is of the opinion that the 
                     53: session layer cannot be used to provide any security service. However, it
                     54: now seems to me that providing encryption at the same level as dialog
                     55: control is a perfectly natural thing to do: Consider for example
                     56: expedited data, or recovery after a T-later failure. The session layer is
                     57: particularly well-placed to know which part of the key-stream to use.o
                     58: 
                     59: Also, it means you can use a Transport Service Bridge ...
                     60: 
                     61: 
                     62: >  >4. does anyone have the T-Serice part of the ISODE manual i could
                     63: >  >borrow?
                     64: 
                     65: Ok, you can borrow mine.
                     66: 
                     67: > 5. Has anyone looked at non  blocking T-Service - X requires this to
                     68: > run well (though it can run over blocking), luckily it doesnt require
                     69: > asynch (phew), but it does like doing writes (T-DATA-REQ's) without
                     70: > haning around... (the converse, polling for reads seems ok since i can
                     71: > use ?select i spose...)?
                     72: 
                     73: Non-blocking session could be quite entertaining...
                     74: (Non-deadlocking session was bad enough).
                     75: 
                     76: 
                     77: Mike

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.