Subject: [Simple] MSRP - ABNF corrections and changes

From: "Peter Ridler" <[email-masked]>
Date: Tue, 17 Aug 2004 13:05:15 -0400

Hi all,

I have come in late to the group, so please forgive me in stating something
that has already be addressed and resolved before. I am building this code
into my test apps and have focused on the ABNF.  I know there has been some
discussion on this already.

I have run it through my ABNF parser and found some of the syntax errors
already discussed.  I have also found other problems relating to references
to other RFC's.

I have made many changes/corrections (nits) but have some real comments to
follow:

In the draft-ietf-simple-messages-sessions-07.txt Section 5 "MSRP URLs"
refers to sections from RFC RFC2396.  RFC2396 has syntax/logic errors so I
recommend we define the MSRP-url in our own ABNF (of course following other
RFC standards as much as possible) as what was done in SIP(RFC3261).  My
attachment contains that ABNF code.  Note that RFC2396 (as well RFC3261) has
logic errors in its hostname/domainlabel/toplabel definitions -- I used the
logic from RFC1035 (converted to ABNF).  Another reason for imbedding the
URL ABNF is that MSRP does not allow escaping where the other RFC's do.  I
also removed the ":" from the userinfo (RFC2396) as this is the password
lead-in char and "a userinfo part MUST NOT contain password information" in
the MSRP-url.

.-.-.-.-.-.-.-.-.-.-.-.-.-

I completed some ABNF code defining namespace, short-status, and text-reason
for the definition of "Status".

.-.-.-.-.-.-.-.-.-.-.-.-.-

Three syntax lines of interest:

   msrp-request = req-start headers [content-stuff] end-line

   content-stuff = *(Other-Mime-Header CRLF)
                   Content-Type 2CRLF data CRLF
   data = *OCTET

The definition of "data" states ZERO to INFINITY, and assuming that we have
defined a MSRP message limit, then data will eat up all the bytes of
information AND the CRLF of "content-stuff" as well as the "end-line"
message as well.  "data" must have some bounds defined for it!

Also content-stuff is OPTIONAL, therefore, "Content-Type" is also OPTIONAL.

>From my point of view I see a need of a little change to the message.
Consider the following:

Put all message control portions in a message header and the payload
strictly data.  This way when the message is received via TCP the message
header can be easily found in the stream (the double CRLF sequences) and
used to define the size/type of the data following (if any).

msrp-req-or-resp = msrp-request / msrp-response
msrp-request = req-start headers CRLF [ data ]
msrp-response = resp-start headers CRLF

"Content-Type" and "Continuation-Flag" should be in the "headers" definition

ADD "Content-Length" to the "headers" to state the length of the message
payload and MUST be in every MSRP message.

Although "headers" are optional in the ABNF syntax -- enforcement of the
headers within the different messages can be specified in the RFC
requirements for message validation.  This would simplify the parsing of the
message.

.-.-.-.-.-.-.-.-.-.-.-.-.-

Peter Ridler

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple