RE: Issue 2: TAG Field Definition

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

While re-reading -sign, some clarification...

Neither -sign-12 nor my proposed text below specifies US-ASCII as
mandatory. As such, any character set would be appropriate. The encoded
characters would just need to be visible and not be SP or colon. As
such, UTF-8 would be perfectly fine in this field. This is also
consistent with RFC 3164.

I will move this assumption into -international-01 and explicitely
define it.

Any opposition against this?

Rainer

> -----Original Message-----
> From: Chris Lonvick [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 03, 2003 7:55 PM
> To: [EMAIL PROTECTED]
> Subject: Issue 2: TAG Field Definition
>
>
> Issue 2: TAG Field Definition
> http://www.employees.org/~lonvick/draft-ietf-syslog-sign-12.ht
> ml#HEADER
>
> From Archive:
> http://www.mail-archive.com/syslog-sec%40employees.org/msg01224.html
> http://www.mail-archive.com/syslog-sec%40employees.org/msg01234.html
> http://www.mail-archive.com/syslog-sec%40employees.org/msg01222.html
>
> Rainer has proposed the following text:
> """
>    The TAG is a string of visible (printing) characters excluding SP,
>    that MUST NOT exceed 32 characters in length.
>
>    The first occurrence of a colon (":") or SP " " character
> terminates
>    the TAG field. Generally, the TAG contains the name of the process
>    that generated the message. It may OPTIONALLY contain additional
>    information such as the numerical process ID of that process bound
>    within square brackets ("[" and "]"). A colon MUST be the last
>    character in this field.
>
>    To be consistent with the format described in RFC 3164, a space
>    character need not follow the colon in normal syslog packets.
> """
>
> However, anyone trying to convey information of
> "Myproc[PID,Threadid]:"
> may have a problem with something like
>
>   syslog[12345,C:\usr\sbin\cron]:
>
> Albert suggests just having "syslog" in the cert/sig-block messages
> but that seems to be inconsistent with the possible formats of the
> normal syslog messages.
>
> Can anyone offer a suggestion to resolve this?
>
>
>