Subject: RFC 4396 issues

From: Alfred Hönes <[email-masked]>
Date: Tue, 7 Mar 2006 18:09:20 +0100 (MEZ)

Hello,
reading the recently published RFC 4396 authored by you,
I found a few flaws I'd like to report
(sequence of items is most important first, this time).

(1)  mis-specification for TYPE 3 Header ???

Repeatedly, the RFC text specifies, e.g. at the beginning of
section 4.1.4, on page 23:

   This header type is used to transport either the entire modifier
   contents present in a text sample or just the first fragment of them.
   [....]

   If a text sample containing modifiers is fragmented, this header MUST
   be used to transport the first fragment or, if possible, the complete
   modifiers.

Subsequently, on page 24, the same section says:

  o The TOTAL/THIS field has the same meaning as for TYPE 2.

|    For TYPE 3 units containing the last (trailing) modifier fragment,
|    the value of TOTAL MUST be equal to that of THIS (TOTAL=THIS).  In
|    addition, TOTAL=THIS MUST be greater than one, because the total
|    number of fragments of a text sample is logically always larger
|    than one.
|
|    Otherwise, if TOTAL is different from THIS in a TYPE 3 unit, this
|    means that the unit contains the first fragment of the modifiers.

Apparently, this does not match the remainder of the specification,
and is not logical in many respects.

Under TYPE=3, the only combinations allowed for TOTAL/THIS should be:
  *  "1 of 1" -- entire modifier contents,  and
  *  "1 of n" -- first fragment of (n>1 fragments of) modifier contents

The former case is explicitely excluded by the present text!
This cannot have been intended.

Hence, the above text should better say:

  o The TOTAL/THIS field has the same meaning as for TYPE 2.

|    For TYPE 3 units, the value of THIS must always be 1 (one).
|    If the unit contains the entire modifier content, TOTAL is 1 (one)
|    as well, otherwise the unit contains the first fragment of the
|    modifiers, and TOTAL must be greater than THIS.

(or similar; e.g., you might always substitute "(0x1)" for "(one)",
or "0x1" for "1 (one)", or use other wording as well.)

(2) encoding of / range of values for the TOTAL and THIS fields

The text (more or less implicitely) specifies the use of the
value range,  1..15,  for these 4-bit fields.

This wastes a bit of bandwidth and excludes from transmission
certain payloads that might (occasionally) require a maximum
of 16 extents.
It would have been useful to specify an "n-1" encoding style
for both fields, i.e. making the (encoded) values  0..15
correspond to a total of  1..16  fragments, or the 1st..16th
fragment, respectively.
Alternatively (but more difficult to implement), a value of
'0' could have been allowed to denote 16 fragments total or
the 16th fragment, respectively.
Both alternatives would lead to simplified implementations,
making the currently possible error case, TOTAL=0, (cf. text
near the end of section 4.1.3) impossible, and hence avoiding
the need to check for it.

Unfortunately, this perhaps cannot be changed now any more.

(3)  textual omission

Near the bottom of page 22, section 4.1.3. says:

     Finally, note that clients MAY use SLEN to buffer space for the
     remaining fragments of a text sample.

It should say:

     Finally, note that clients MAY use SLEN to allocate buffer space
     for the remaining fragments of a text sample.

It might be very useful to correct item (1) as soon as possible
to avoid confusion.  Item (3) is straightforward.

I propose that you submit an Authors' Errata Note by sending email
to the RFC-Ed. for publication on the RFC Errata web page, making
deliberately use of the material presented above for items (1) and (3).
Alternatively, I could submit an Errata Note on my own, covering these
two items; to this end, a statement of your consent for item (1) would
be needed, since this is a correction of normative content.

Please comment.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+