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
