Subject: [Ietf-calsify] Section 4.8.4.7 and 6: 255 characters versus 255 octets

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Mon Aug 21 19:53:57 2006

In section 4.8.4.7 Unique Identifier of RFC 2445 it says:

 > Implementations MUST be able to receive and persist values of at
 > least 255 characters for this property.

And, in Section 6 Recommended Practices it also says:

 > 6. An implementation can truncate a "SUMMARY" property value to 255
 >    characters.

In both sections I propose to change "255 characters" to "255 octets".

Cheers,
Bernard

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Mon Aug 21 20:02:18 2006

Hi Bernard,

> In both sections I propose to change "255 characters" to "255 octets".

+1

-- 
Cyrus Daboo

---

From: alexey.melnikov at isode.com (Alexey Melnikov)
Date: Tue Aug 22 03:36:50 2006

> In both sections I propose to change "255 characters" to "255 octets".

Yes.

Is this affected by ABNF for NON-US-ASCII? I.e. if we choose to define 
NON-US-ASCII as:
     NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4
     ; UTF8-2, UTF8-3, and UTF8-4 are defined in RFC 3629.
then should we allow truncation at any octet?

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Tue Aug 22 06:37:21 2006

Hi Alexey,

> then should we allow truncation at any octet?

Good point. As per line folding, I think what should be said is something 
like 'truncation can occur at 255 octets provided it does cause a 
multi-octet character to be split. If there is a multi-octet character at 
the 255 octet position, then truncation can occur at the next whole 
character below 255 octets'. Of course that could still result in some 
weirdness with combining characters etc

-- 
Cyrus Daboo

---

From: sroberts at uniserve.com (Sam Roberts)
Date: Tue Aug 22 10:44:46 2006

> like 'truncation can occur at 255 octets provided it does cause a 
Do you mean "does NOT cause"?