Idiot's guide to Features (was: RE: Channel response serialization)

Paul Andrews wrote:
> I don't suppose you have an 'Idiots Guide to 
> Adding Features' do you?

A Beep feature gets advertised as part of the greetings messages. A Beep
"x-outoforder" feature might look something like the following: (Note:
If registered with IANA, this feature would be 'outoforder'. The "x-"
prefix is only for things not IANA registered.)

    L: <wait for incoming connection>
    I: <open connection>
    L: RPY 0 0 . 0 999
    L: Content-Type: application/beep+xml
    L:
    L: <greeting features='x-outoforder'>
    L:    <profile uri='http://xml.resource.org/profiles/TLS' />
    L: </greeting>
    L: END
    I: RPY 0 0 . 0 999
    I: Content-Type: application/beep+xml
    I:
    I: <greeting features='x-outoforder'/>
    I: END

To register a feature, you fill out the Feature Registration Template
which is in section 5.2 of the BEEP RFC. The registration might be
something like: 

============
   Feature Identification: 'x-outoforder'

   Feature Semantics: This feature permits a BEEP peer acting in 
    the server role to process "MSG" messages for a given channel 
    in any order it chooses. This is a relaxation of the requirement 
    for "in-order" processing defined in RFC3080 at Section 2.6.1.
    If both the BEEP peer acting as the initiator and the BEEP peer
    acting as the server send greetings messages containing the
    x-outoforder feature token, both BEEP peers must assume that
    the reply ordering constraints of RFC3080 at Section 2.6.1 do 
    not apply to the current attachment.

   Contact Information: 
	Postal Address of author:
	Electronic Address of author:

===========

It is that simple -- unless I'm a real idiot...

		bob wyman