[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Simple] Re: ABNF Issues in draft-ietf-simple-message-sessions-08.txt
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
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple