RE: syslog-int

[Anton Okmianski <[e-mail]>]

RFC2277 "IETF Policy on Character Sets and Languages" could be of use
for syslog-international draft:
ftp://ftp.isi.edu/in-notes/rfc2277.txt

Of note:

 - It clearly favors UTF-8.  Does not mention UTF-7.
 - It seems to argue that language must be identified.

Anton.

> -----Original Message-----
> From: Anton Okmianski [mailto:[e-mail]]
> Sent: Tuesday, August 12, 2003 11:30 AM
> To: [e-mail]
> Cc: Nathan Sowatskey; David Bainbridge
> Subject: RE: syslog-int
>
>
> 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-intern
> ational-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.
>
>
>
>
>

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