Hi Albert,
sorry for the sluggish reply, too much going on in parallel.
I think I basically agree with your idea - some comments below...
On Tue, 2003-09-30 at 12:03, Albert Mietus wrote:
> Based on Rainers text, the issue's/problems of Chris, and the
> expirence in implementing it. The following text is proposed to be
> included in syslog-sign.
>
> """
> The TAG is a string of visible (printing) characters excluding SP,
> that MUST NOT exceed 64 characters in length.
> The first occurrence of a SP (space) will terminate the TAG field,
> but is not part of it.
> It is RECOMMENDED to terminate the TAG with a colon (':'), which if
> used, is part of the TAG.
>
> The TAG is used to denote the sender of the message. And is
> RECOMMENDED to have the following syntax:
>
> TAG = full-stat-id full-dyn-id ':'
> full-stat-id = path path-sep progname
> full-dyn-id = '[' proc-id thread-part ']'
> path = VISUAL *
> path-sep = ( '/' | '\' )
> progname = VISUAL *
> proc-id = ALFANUM * ; recommended: number
> thread-part = ( EMPTY | thread-sep ALFANUM )
> thread-sep = VISUAL ; recommended: ",", or ':', or '.'
> EMPTY = "" ; nothing!
> VISUAL = ([a-zA-Z0-9...], excusing '['
>
> (hope I have the this syntax OK --please correct ALbert)
I think it needs a little work - will try to create something in your
spirit. I am not sure if I can finish that today, so I send this message
as is...
>
> The PROGNAME part is special, as it is frequently used by relays to
> determine the routing of a message. As a note to implementors: it
> can be found by getting the visual part before the first occurrence
> of '[', and after the last '\' of '/' part of that segment.
mmhhh... I can see the reasoning for this, but do you think we really
need to allow [ inside the path? Without it, implementing would be
easier. In my experience, parsing strings backwards (as would be
required) seems somehow more error-prone than forward parsing (but maybe
it's just me failing in those cases ;))
What do the others think?
>
> An example of a TAG is: (without the quotes)
> "/path/to/PROGNAME[123,456]:"
>
> Systems that use both process-ID's and thead-IDs, SHOULD fill both
> the proc-id and the thread-part. For other systems it is
> RECOMMENDED to use the proc-id only.
I would like to see a wording like "main" and "sub identifier". This may
be process and threads, but it may have other uses, to (in different
environments). For example, a multiprocess architecture may decide to
put the main pid into the process and the worker pid into the thread -
you see what I mean? We could of course recommend to use main for pid
and sub for thread id... just an idea.
>
> 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.
Rainer
