Re: Issue 2 (TAG)

[Rainer Gerhards <rgerhards@hq.adiscon.com>]

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