[BXXPwg] proposal for 1:N interactions

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


I also wanted to propose that the content-type be moved from the header into the payload. While I have been working on our implementation of BXXP this is something that hasn't felt quite right.

content-type is treated more like part of the message (other than the fact that it isn't accounted for in the payload length in the header). content-type is only sent in the first frame of a message as though it is part of the payload, it has to be buffered (in the TCP mapping this causes it to be counted against the available channel window) and delivered to the service/application with the payload, and BXXP doesn't use it for anything (e.g. validating the payload as complying with the content-type).

The behavior of channel 0, where the service using the channel knows the content-type, is more cohesive and the implementation is cleaner.

I would also like to be able to specify a default content-type as part of the profile registration or as an attribute of each profile in the channel start message. If a service will be sending messages with different content-types on the same channel then it would be send the content-type as part of the message in the BXXP payload. 

>>> "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

#######