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
RE: [Syslog] #7, field order
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
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
Re: [Syslog] #7, field order
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 *shrug* I'm just repeating what someone else thought was an issue. 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 | ...'). You want to use - to mean that there is no value for that field present, therefore you must make the grammar support the distinction between having a value there and not having a value there. On the HOSTNAME, I am refering to STD 13, which I consider to be sufficient. Take note that IP V6 representations must be allowed. Right. So look at what your definitition allows and then compare that with STD 13 (which is RFC 1035 that I was referring to.) RFC 3490 deals with internationalising domain names. I'd suggest reading section 2.3.1 of STD 13 more closely, along with the section in 3.1 around where it says strongly recommend. I think you are far better off just saying 'See RFC ' or 'See IETF for latest hostname specification' than trying to nail it here. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] #7 field order
I was thinking that PRI is also not optional. Tom Petch - Original Message - From: Rainer Gerhards [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 30, 2005 10:06 AM Subject: RE: [Syslog] #7 field order I just got private mail if a missing field is denoted by -. This is the case. Optional fields should be all but VERSION. Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards Sent: Wednesday, November 30, 2005 9:37 AM To: [EMAIL PROTECTED] Subject: [Syslog] #7 field order WG, there has not been much discussion about the header fields and their order recently. I think this is a sign the issue has been settled. To make sure I got the right understanding of the resulting consensus, I propose that we use the following format: PRIVERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP [SD-ID]s SP MSG That is the format that also proven to be quite useful during my proof-of-concept implementation. If somebody objects, please do that now. Thanks, Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] #7 field order
Hi, Can you please ask those who are sending you private messages to make their points on the mailing list, as is appropriate for IETF WG discussions? dbh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards Sent: Wednesday, November 30, 2005 4:07 AM To: [EMAIL PROTECTED] Subject: RE: [Syslog] #7 field order I just got private mail if a missing field is denoted by -. This is the case. Optional fields should be all but VERSION. Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards Sent: Wednesday, November 30, 2005 9:37 AM To: [EMAIL PROTECTED] Subject: [Syslog] #7 field order WG, there has not been much discussion about the header fields and their order recently. I think this is a sign the issue has been settled. To make sure I got the right understanding of the resulting consensus, I propose that we use the following format: PRIVERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP [SD-ID]s SP MSG That is the format that also proven to be quite useful during my proof-of-concept implementation. If somebody objects, please do that now. Thanks, 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
RE: [Syslog] #7 field order
David, Can you please ask those who are sending you private messages to make their points on the mailing list, as is appropriate for IETF WG discussions? That's what I typically do. But what if they are not willing to do that and the point is important? Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] #7 field order
Anton, Thanks for the clarification. Your wording is correct. SD-ID will also have - to indicate that it is undefined, which in this case actually means there is none. Rainer -Original Message- From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED] Sent: Thursday, December 01, 2005 7:11 PM To: Rainer Gerhards; Tom Petch; [EMAIL PROTECTED] Subject: RE: [Syslog] #7 field order Rainer, a better way to phrase this is may be that none of the fields are optional (except for maybe SD, depending on how you define the separators). Some fields just have special values which are allowed to designate an undefined value. So, the fields are always there. Anton. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards Sent: Thursday, December 01, 2005 10:45 AM To: Tom Petch; [EMAIL PROTECTED] Subject: RE: [Syslog] #7 field order Tom, well-spotted. Indeed, PRI is NOT optional. The only one, as far as I am concerned. Rainer -Original Message- From: Tom Petch [mailto:[EMAIL PROTECTED] Sent: Thursday, December 01, 2005 12:35 PM To: Rainer Gerhards; [EMAIL PROTECTED] Subject: Re: [Syslog] #7 field order I was thinking that PRI is also not optional. Tom Petch - Original Message - From: Rainer Gerhards [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 30, 2005 10:06 AM Subject: RE: [Syslog] #7 field order I just got private mail if a missing field is denoted by -. This is the case. Optional fields should be all but VERSION. Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards Sent: Wednesday, November 30, 2005 9:37 AM To: [EMAIL PROTECTED] Subject: [Syslog] #7 field order WG, there has not been much discussion about the header fields and their order recently. I think this is a sign the issue has been settled. To make sure I got the right understanding of the resulting consensus, I propose that we use the following format: PRIVERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP [SD-ID]s SP MSG That is the format that also proven to be quite useful during my proof-of-concept implementation. If somebody objects, please do that now. Thanks, 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
WG, there has not been much discussion about the header fields and their order recently. I think this is a sign the issue has been settled. To make sure I got the right understanding of the resulting consensus, I propose that we use the following format: PRIVERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP [SD-ID]s SP MSG That is the format that also proven to be quite useful during my proof-of-concept implementation. If somebody objects, please do that now. In your other email, you say that - is for a missing field - I was curious about whether all fields were mandatory or what was to be done if you wanted to miss one out, but you've answered that. The HOSTNAME field should be constrained, in its definition, to match that accepted for FQDNs. PRINTUSASCII is too wide. I believe you need to read RFC 1035. Similarly, I'd like to see APP-NAME, PROCID and MSGID refined to be less than the entire character set. A contradiction in syslog-protocol is allowing PRINTUSASCII for fields but a field of - is used to indicate it is not there. The only thing I would like to see considered is keeping a ':' to mark end of headers and start of message. Or is this pointless ? I'm thinking from a perspective of parsing them with awk/grep. If, for example, I can search for either ']: ' or '-: ' and know that what follows would be the messageis that sensible ? Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
