Not sure I have grasped the problem yet but the cases you cite would appear to be covered by rules of the form, using pseudo-English as a shortcut,
FIELD = ONECHAR / MORECHAR ONECHAR = <anyprintable character except hyphen-minus> MORECHAR = <anyprintable character> 1*<any printable character> which prohibits - but allows -- i -id- etc (but not:-) Tom Petch ----- Original Message ----- From: "Rainer Gerhards" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, December 21, 2005 6:16 PM 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 > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
