Hi,

The editors of RFC 4234 "Augmented BNF for Syntax Specifications:
ABNF" might be willing to help you craft the appropriate ABNF grammar.


David Harrington
[EMAIL PROTECTED]

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards
> Sent: Wednesday, December 21, 2005 12:17 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [Syslog] #7, field order
> 
> David, Darren,
> 
> even though no responses indicated we actually need to fix this, I
> wanted to at least try an alternate ABNF. However, I did not find a
> suitable one. Probably I am not smart enough to find it, so I 
> am asking
> if somebody else could come up with one (and if not, that would be a
> definite answer to the original question).
> 
> Darren suggested something along the lines of
> 
> > > field ::= missing | non-dash | PRINTUSASCII*1 PRINTUSASCII*255
> > > missing ::= "-"
> 
> However, that doesn't seem to catch all cases. So I tried to 
> craft some
> ABNF that allows all cases, which includes the strings below 
> (each on a
> separate line)
> 
> --
> -id-
> -id
> id-
> i-d
> i
> 
> but disallows
> 
> -
> 
> However, I did not succeed in this effort. Either I do not know
enough
> about ABNF (may well be) or it is actually impossible to 
> describe such a
> beast in just the grammar. From the implementors point of 
> view, I think
> it is pretty easy to parse everything and then compare it to 
> a sole "-".
> But that's not the point of this question. The question is if 
> there is a
> way to make the *parser* do the differentiation.
> 
> I'd appreciate any comments on this.
> 
> Rainer
> 
> > -----Original Message-----
> > From: David B Harrington [mailto:[EMAIL PROTECTED] 
> > Sent: Thursday, December 15, 2005 6:50 PM
> > To: Rainer Gerhards; 'Darren Reed'
> > Subject: RE: [Syslog] #7, field order
> > 
> > Hi,
> > 
> > Having a public feud won't help us achieve our goals. 
> > 
> > I suspect I fall into the same category as most of the 
> working group:
> > I'm not convinced there is a serious problem.
> > I'm not sure which is the best technical solution. 
> > I'm not convinced it matters which way we do it.
> > I would be more convinced if multiple implementors said it's a
> > problem.
> > 
> > As an experienced WG chair, I am not convinced there is consensus
to
> > solve the problem. As an experienced WG chair, I've had one person
> > claim there is a problem, and had the WG advance the spec without
> > solving the problem, and had the problem come back to bite us in
the
> > backside.
> > 
> > Here's what I suggest as a way forward on this issue.
> > 
> > Will the implementors listening in this WG tell us if they 
> think there
> > is a serious problem with the "-" and <space> and the ABNF,
et.al.,
> > and tell us how to solve it in a manner that you would find
> > acceptable? If it's a problem let's get multiple voices working on
a
> > solution. If it's not a problem, let's reach consensus it is not a
> > problem and move on.
> > 
> > Thanks,
> > David Harrington
> > [EMAIL PROTECTED]
> > 
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] 
> > > [mailto:[EMAIL PROTECTED] On Behalf Of 
> Rainer Gerhards
> > > Sent: Thursday, December 15, 2005 4:39 AM
> > > To: Darren Reed
> > > Cc: [EMAIL PROTECTED]
> > > Subject: [Syslog] #7, field order
> > > 
> > > Darren,
> > > 
> > > that's why I take your comment not seriously: 
> > > 
> > > > > data for that field.
> > > > > 
> > > > > If you don't understand the difference here, I think the 
> > > fields need
> > > > > to be defined something like this:
> > > > > 
> > > > > field ::= missing | non-dash | PRINTUSASCII*1
PRINTUSASCII*255
> > > > > missing ::= "-"
> > > > 
> > > > And as someone else pointed out to me, PRINTUSASCII 
> > > includes the space
> > > > charactr (0x20), which is used as the field delimeter.  
> > > This needs to
> > > > be fixed too.
> > > 
> > > If you would look at the ABNF, you would find
> > > 
> > > PRINTUSASCII    = %d33-126
> > > 
> > > This is the problem with your comments: you claim things while
at
> > the
> > > same time you show that you are uninformed (at best). I 
> > > believe in peer
> > > review, not in peer rumor... I assign peers some credibility and
> > yours
> > > has gotten quite low over time. It's my personal judgement, 
> > > but again I
> > > am stating everything honestly on-list so that others 
> > > thinking your way
> > > can add their comments, which would obviously increase 
> their weight.
> > I
> > > guess that's common sense and not just "my party" ;)  
> [but I have to
> > > admit that I personally do not care about what you think about
me
> > and
> > > "my party"].
> > > 
> > > As another technical comment, "-" for me is proper field 
> > > content. It is
> > > just a special value which indicates a void value and these
> > semantics
> > > are clearly described in the text. I have to admit I do not 
> > > know any way
> > > how I could add such semantics to the grammer - your grammer 
> > > above does
> > > the same as my grammer with the exception that it is more
verbose.
> > The
> > > resulting parser will be the same (because you obviously allow
"-"
> > by
> > > 'missing | ...').
> > > 
> > > On the HOSTNAME, I am refering to STD 13, which I consider to be
> > > sufficient. Take note that IP V6 representations must be
allowed.
> > > 
> > > So all in all, I do not see any need for change (maybe the name
> > > PRINTUSASCII, as it seems to be confusing to people not involved
> > with
> > > the work - no, not (just) kidding, this might actually be 
> an issue).
> > > 
> > > Rainer
> > > 
> > > _______________________________________________
> > > Syslog mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/syslog
> > > 
> > 
> > 
> > 
> 
> _______________________________________________
> Syslog mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/syslog
> 



_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog

Reply via email to