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
RE: [Syslog] #7, field order
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
