RE: syslog-int

[Anton Okmianski <[e-mail]>]

Hi!

I assume this is the forum to provide the feedback on this draft.

> 	Title		: Syslog-international Protocol
> 	Author(s)	: R. Gerhards
> 	Filename	: draft-ietf-syslog-international-00.txt
> 	Pages		: 13
> 	Date		: 2003-8-1
http://www.ietf.org/internet-drafts/draft-ietf-syslog-international-00
.txt


First of all, thanks for putting the draft together!

1. I think it was a good idea to put language headers into the MSG
part as opposed to other syslog fields. This would allow me, for
example, storing the message on disk in the same format and/or re-use
the language header even when bypassing syslog.

2. The LANGUAGE field.  Is it necessary?  Can it be omitted?  I can
easily see a situation where an application supporting foreign
languages does not know the source language.  For example, my
applications takes usernames in any language (in Unicode).  Now, I
need to produce a syslog message which has the username in it. What am
I going to put in the LANGUAGE field?

Also, there can be situations (bizarre as they are) when a message
contains multiple languages in it. With Unicode-based encodings, it is
not a problem.  What happens in this case?

I'd propose removing the LANGUAGE field.

3. RFC1766 referenced in the LANGUAGE field spec is officially
obsolete.  Need to address it one way or another if the LANGUAGE field
stays?

4. I am concerned about attempting to support ALL encodings and ALL
charsets. Is it necessary?  If this is a new standard, why do we need
to provide for support of all legacy encodings?  Why can't we just
standardize on Unicode encoded as straight binary UTF-8 or UTF-7?
Maybe also provide for support of UTF-16 for more compact
representation of Asian languages.  Either one will cover all
languages and would not require getting into the business of
interpreting locale/language specific charsets and many encodings.

So, can we do away with the CHARSET field and only use Unicode-based
and US-ASCII encodings in the ENCODING field?

5. Even if we support multiple encodings, it would probably help to
specify a few that  MUST be supported.  Otherwise, how do we ensure
interoperability if each implementation can choose its own set of
supported encodings/charsets?

6. Can we specify that the absence of the header should be interpreted
as UTF-8 encoded message?  A UTF-8 compliant syslog daemon will be
backwards compatible as it would be able to receive message sent in
plain US-ASCII as this range of characters is encoded identically.

7. Just a minor thing.  The spec and examples show the special prefix
as "@#i18n", but there is a note in the spec that the "i" should be
capital "I".  Why not change it in the examples then?

8. With internationalization of messages, the length of messages will
inevitably grow.  Should we provide for multi-part messages to
overcome the 1024 byte limit?  Multi-part messages could have the same
standard syslog header along with some additional part-seq-number.  I
guess this also required msg-seq-number.  If we don't deal with
multi-part messages as part of syslog RFC, applications will invent
their own mechanisms to identify messages that belong together.  A
standard mechanism would be nice.

Thanks!

Anton.

------------------------------