Tom, loool - thanks, yes exactly this is it. Believe it or not, I've been banging my head for hours hours and I still didn't get it. Silly me ;)
Thanks for the help. Rainer > -----Original Message----- > From: Tom Petch [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 22, 2005 10:27 AM > To: Rainer Gerhards; [EMAIL PROTECTED] > Subject: Re: [Syslog] #7, field order > > 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
