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     ! 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.