Subject: [Syslog] review of draft-ietf-syslog-protocol-17

From: [email-masked]
Date: Mon, 2 Oct 2006 15:23:37 -0400 (EDT)

I reviewed this draft and believe it is in good shape and reflects the
discussions on the list and consensus of the working group. After one more
round, it should IMO be ready to go to the AD.

In addition to or in agreement with the other review comments that have
been posted, I sent some editorial comments to the author and also made a
couple of small comments about:

1. replacing the reference to 3513 with 4291
2. clarifying the text about when UTF-8 versus "plain ASCII" is present in a
   SD-PARAMs versus the MSG
3. simplifying the overloaded use of HOSTNAME, Hostname, and hostname in
   Section 6.2.4.

The details are below.

Rich Graveman

------------------
   If an IPv4 address is used, it MUST be in the format of the dotted
   decimal notation as used in STD 13 [4].  If an IPv6 address is used,
   a valid textual representation described in RFC 3513 [10], Section
   2.2, MUST be used.
* RFC 4291 (DS) obsoletes 3513. Section number 2.2 is still correct.
-------------------from 6.2.4
   The NILVALUE SHOULD only be used when the sender has no way to obtain
   its real hostname.  This situation is considered highly unlikely.
* We now have HOSTNAME, Hostname, and hostname. Maybe just:
* s/its real hostname/any of the names or addresses listed above/
-------------------from 6.4
   If a sender encodes MSG in UTF-8, the string MUST start with the
* s/MSG/a MSG with international characters/
* Comment: Above, if I am correct, the SD-PARAM MUST be encoded in UTF-8,
* even though the examples show "plain ASCII." Technically, this is
* correct, becasue plain ASCII is legal UTF-8. But here, plain-ASCII
* UTF-8 should not require a BOM.
   Unicode byte order mask (BOM), which for UTF-8 is ABNF %xEF.BB.BF.
   The sender SHOULD also include an "meta" SD-ID with an "enc"
   parameter within the STRUCTURED-DATA.  The sender MUST encode in the
   "shortest form" and MAY use any valid UTF-8 sequence.

   If a receiver receives MSG starting with a BOM, it MUST assume UTF-8
   encoding.  For the reasons outlined in UNICODE TR36 [13], section
   3.1, a receiver MUST NOT interpret messages in the "non-shortest
   form".  It MUST NOT interpret invalid UTF-8 sequences.

   If a sender does not encode MSG in UTF-8, the string MUST NOT start
   with the Unicode BOM.  If MSG is not encoded in UTF-8, the sender MAY
   use any other encoding (including binary data).
* If the above comment makes sense, then turn it around and say:
* If the MSG string starts with the Unicode BOM, then it MUST be interpreted
* as UTF-8.

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: [email-masked]
Date: Tue, 3 Oct 2006 14:51:29 -0400 (EDT)

I reviewed this draft and found it well written and complete. I believe it
is ready for publication.

I had only one minor suggestion upon reading the text:

In the section on out-of-order delivery, one may mention using the meta
Structured Data sequenceId, if present, as well as time stamps.

Rich Graveman