On Mon, 2003-10-06 at 09:19, Albert Mietus wrote: > Hello again:-) > > > > Receivers SHOULD, to be consistent with the format described in > > > RFC3164, accept TAGs that terminate with a single colon, without a > > > space following it. Then the colon is both the last character of > > > that TAG, and the field separator with the next field (MSG). > > > > I think you must somehow revert back to my wording. Above you say that > > SP MUST terminate the tag. If you allow colon to terminate, too (I agree > > on this need), you must also allow it - otherwise it is > > confusing/inconsistent. > > With the syntax I tried to express how a TAG SHOULD be. Senders should > use that, and receivers should expect it.
So we should probably move this into some MUST/SHOULD wording. I think the ABNF already deals with this. > > However, the real world sometime differs. Like existing > syslog(d)'s. Which may (as rfc3164 describes) not use a SP to separat > field and use ":" to terminate. > > The quoted part describes how a reciever shoul deal those "not > standard" logmessages. > > Note: we can not acccept colon as a terminator. E.g. Windows used it > as in "C:\PATH\PROG[main, minor]". Mmmmhhh.. as of your earlier posting, I think this would be possible. Think of this nice path name "C:\Program Files\GreatSyslogd[main, minor" Do you see the space in it ;) Isn't life easy... BTW: That was my point on backwards parsing - I think you must parse it backwards so that the *last* occurrence of the character is acutally the terminator. But space, as above, is really hard to cope with. It should probably be forbidden. > > By describing it, (vaguely) I leave it to the implementor how to > handle it exactly. When implementing for Unix-only this "requirement" > may get another priority the in a mainly Windows one. I see your point. By describing it, you place some burden on the implementor, but the implementor at least is forced to think about it. I fear, however, that we will see broken implementations as with the SP in pathname above. But isn't that, too, an argument to not allow ":". After all, when we disallow SP, we can disallow other characters, too - the implementor would need to parse the file name in any way. OK, he may decide not to do this... But can we really care for this? Rainer