[BXXPwg] proposal for 1:N interactions

Huston Franklin HUSTON@novell.com
Tue, 29 Aug 2000 10:46:50 -0600


I like the proposed changes.
One question, will section 2.6.1 "that BXXP peer must generate the corresponding "RSP" messages in the same order as the "REQ" messages are received" apply for MSG/RPY and MSG/ERR exchanges and an exception be added for MSG/ANS/NUL exchanges?

--Huston

>>> "Marshall Rose" <mrose+mtr.netnews@dbc.mtview.ca.us> 08/28/00 06:33PM >>>
here is what joe and i propose. please read it carefully and comment.

thanks,

/mtr

Reminder of the basics:

    - within a channel, orderly delivery of frames
    - between channels, no constraints on ordering of frames
    - a message number (formerly known as a serial number), may not be
      reused until an acknowledgement (of some kind) is received, and
      the msgno space is big (31 bits)


Change Summary:

    - frames are renamed:
        REQ split into MSG
        RSP split into RPY (positive), ANS/NULL (positive) and ERR
(negative)

    - 1:N interactions, where N>1, are handled by ANS:
        the ansno parameter allows interleaving of answers
        as soon as the more bit indicates that an ANS is complete, the ansno
        may be reused for that msgno

    - 1:0 interactions still require an acknowledgement from the remote
side:
        otherwise, we could run out of msgno's
        and it's probably needed for end-to-end correctness

    - common parameters are re-ordered:
        channel numbers appear in each frame (and are 31-bits wide)
        serial numbers now called message numbers (and are per-channel)

    - mime headers are now part of the payload


Possible Interactions:

        C: MSG
        S: RPY  ; message number may not be reused by C: until RPY received

or

        C: MSG
        S: ERR  ; message number may not be reused by C: until ERR received

or

        C: MSG
        S: ANS
        S: ANS
        S: ANS
        S: NUL  ; message number may not be reused by C: until NUL received
or

        C: MSG
        S: NUL  ; message number may not be reused by C: until NUL received

In other words, you send a MSG and get back one of:

        - a RPY
        - an ERR
        - 0 or more ANS, followed by a NUL


Revised ABNF:

    frame      = header payload trailer / mapping

    header     = msg / rpy / err / ans / nul

    msg        = "MSG" SP channel SP msgno SP more SP seqno SP size CR LF

    rpy        = "RPY" SP channel SP msgno SP more SP seqno SP size CR LF

    ans        = "ANS" SP channel SP msgno SP more SP seqno SP size
                                                      ansno         CR LF

    err        = "ERR" SP channel SP msgno SP more SP seqno SP size CR LF

    nul        = "NUL" SP channel SP msgno SP         seqno         CR LF


    channel    = 0..2147483647

    msgno      = 0..2147483647

    more       = "." / "*"

    seqno      = 0..4294967295

    size       = 0..2147483647

    ansno      = 0..2147483647


    mime       = <MIME Content {entity-headers} from RFC 2045>

    payload    = [mime] CR LF *OCTET


    trailer    = "END" CR LF


    mapping    = ;; each transport mapping may define additional frames

#######