Subject: [Simple] Re: ABNF Issues in draft-ietf-simple-message-sessions-08.txt

From: Ben Campbell <[email-masked]>
Date: Tue, 12 Oct 2004 22:24:40 -0500

Sorry for taking so long in getting back to this one. Comments inline.

On Aug 27, 2004, at 10:10 AM, Peter Ridler wrote:

>
> Hi all,
>
> I still see a lot of issues in the new
> draft-ietf-simple-message-sessions-08.txt for ABNF Syntax.  My ABNF 
> Compiler
> throws out a lot of errors still.  Here is may list (going from top
> down).....
>
>
> 1) Missing x on "mSend" and "mREPORT" rules (should be)
>
> mSEND = %x53.45.4e.44 ; SEND in caps
>
> mREPORT = %x52.45.50.4f.52.54; REPORT in caps

OK, will fix.

>
> 2) Grouping not required on "headers" rule (nit)
>

Sorry, I don't understand the comment.

> 3) Section 5 defines the MSRP URL with ABNF but not present in Section 
> 8
> (shown here with corrections)
>
> ; "userinfo", "hostport", and "unreserved" are detailed in RFC2396
>
> MSRP-url = msrp-scheme "://" [userinfo "@"] hostport ["/" resource] ";"
> transport
>
> msrp-scheme = "msrp" / "msrps"
>
> resource = 1*unreserved
>
> transport = "tcp" / ALPHANUM

The only change I see is the removal of the "s" char in MSRP-urls 
(which was a typo.) Are there other changes I have missed? Also, I 
_think_ you are recommending moving this to section 8, correct?

>
>
> 4) "To-Path" and "From-Path" use "URL" should be "MSRP-url" as follows
>
> To-Path = "To-Path:" SP MSRP-url *( SP MSRP-url )
>
> From-Path = "From-Path:" SP MSRP-url *( SP MSRP-url )

OK

>
> 5)"namespace", "short-status" and "text-reason" are undefined could 
> be...
>
> namespace = "000"
>
> short-status = "200"  ; OK
>              / "400"  ; Bad Request
>              / "403"  ; Forbidden
>              / "415"  ; Unsupported Media Type
>              / "426"  ; Request is only allowed over TLS
>              / "481"  ; Session Does Not Exist
>              / "506"  ; Request already bound on another connection
>
> text-reason = *(VCHAR / WSP)	; All visible charcters / SP / HTAB 
> (defined
> in RFC2234 CORE)

OK

>
> 6) Rule "DUmMy" should maybe labled "Status" !
>
> Status = "Status:" SP namespace SP short-status [SP text-reason]
>

Uhm, oops!

> 7) "alphanum" on rule "ident-char" should be "ALPHANUM"  (nit)
>
> ident-char = ALPHANUM / "." / "-" / "+" / "%" / "="

OK

>
> 8) Double x on second range on rule "token"
>
> token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / 
> %x5E-7E)
>

OK

>
> 9) "HT" is defined in RFC2234 CORE as "HTAB"
>
> qdtext = SP / HTAB / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII

OK

>
> 10) "DQUOTE", "CRLF" , "HT" as "HTAB", "SP", "DIGIT" are defined in 
> RFC2234
> CORE.  Should NOT redefine them.
>

OK

> 11) "LOWALPH" not really used, "ALPHAHUM" can be defined as: (nit)
>
> ALPHAHUM = ALPHA / DIGIT

OK

>
>
> 12) "Content-ID" and "Content-Description" NOT defined in RFC2045
>     "Content-Disposition" NOT defined in RFC2183
>     "mime-extension-field" should be defined as "MIME-extension-field" 
> for
> RFC2045 (nit)
>
>
> Other-Mime-Header = id                    ; Content-ID defined in 
> RFC2045
>                   / description           ; Content-Description 
> defined in
> RFC2045
>                   / disposition           ; Content-Disposition 
> defined in
> RFC2183
>                   / MIME-extension-field  ; defined in RFC2045
>
>

Sorry, I am not sure I understand. Are you saying I have the wrong RFC 
numbers? Or just that I should present this differently?

> 13) On rule "hname", "alpha" should in uppercase (nit)
>
> hname = ALPHA *token

OK

>
> 14) On rule "utf8text" should use "HTAB" insead of "HT" (RFC2234 CORE)
>
> utf8text = *(HTAB / %x20-7E / UTF8-NONASCII)
>

OK

> 15) 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!
>
> Here is a suggestion to make "data" more clear (and conform to ABNF 
> RFC2234
> logic rules)
>
> a) You could use "text" as defined in RFC2822 (because of
> MSRP->RFC2183->RFC2045->RFC2822)
>
> data = *text    ; defined in RFC2822
>
> ---- OR ------
>
> b) You could use "ptext" as defined in RFC2045.  This allows for 
> escaped
> bytes using "=" (hex-octet)
>
> data = *ptext    ; defined in RFC2045
>
> ---- OR ------
>
> c) Just define our own type (similar to text in RFC2822)
>
> data = *(%x01-09 / %x0B-0C / %x0E-7F)	; Characters excluding CR and LF
>
> ---------------
>
> I like point #b, but could live with any of them.....

If I understand right, your point is we need to exclude CR and LF from 
data, so that we can find the end. Problem is, the body may well 
contain CRs and LFs. That would seem to preclude A and C. And I don't 
really like having to escape things in the body if we can possibly 
avoid it.

We had assumed that an MSRP parser would scan for occurrence of the 
"-------" and transaction-ID in the end-line. These values are chosen 
to make it highly unlikely they will collide with the message content. 
But I don't know a way to express this concept in ABNF, at least not 
with the formality needed to make a parser created by an ABNF compiler 
to just do the right thing.

Does anyone else have thoughts on this matter? Is this lever of ABNF 
formality required?

> ---Peter

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