Subject: iCalendar - "octets" question

From: "Shannon J. Clark" <[email-masked]>
Date: Tue, 27 Nov 2001 12:51:02 -0600

A developer just asked me "What is an octet?"

Perhaps this is fairly basic - but it does not appear to be clearly defined
anywhere in our standard - and it is used in section 4.1 on content lines.
In general my developer (and I) expected to read "75 characters" - but
instead read "75 octets" - does this related to multi-byte encoding?

In any case I suspect that a simple definition of the term would help.

thanks,

Shannon

Shannon J. Clark
President - JigZaw, Inc
1.800.4.JIGZAW (454.4929)
[email-masked]
www.jigzaw.com

---

From: "John Stracke" <[email-masked]>
Date: Tue, 27 Nov 2001 15:04:39 -0500

>A developer just asked me "What is an octet?"

A byte.  The word's use in RFCs seems to trace back to the days when 
people could still disagree on how many bits in a byte.

/==============================================================\
|John Stracke                   |Principal Engineer            |
[email-masked]  |Incentive Systems, Inc.       |
|http://www.incentivesystems.com|My opinions are my own.       |
|==============================================================|
|In the long run, there is no middle ground between justice and|
|genocide.                                                     |
\==============================================================/

---

From: [email-masked]
Date: Tue, 27 Nov 2001 19:47:36 -0500

Shannon replied on 11/27/2001 03:19:41 PM:
> Does this mean that in a multi-byte object you SHOULD wrap 
> potentially in the middle of character? 

Id agree w/John that it is a MAY rather than a SHOULD.  The folding / 
unfolding should be happening at a different level than the character set 
encodings.

>                                         Does this have any potential
> problems? 

Only if someone built a bad parser / generator that mixed in character set 
encodings as part of the folding / unfolding process.  It can be done but 
you cannot spec out stupidity...

>           Or would it be recommended that the wrapping happen only 
> at the ends of a character - i.e. at 73 or 74 octets if 75 might 
> cause a break of a character?

Keep the layers properly separated and this is a non-issue.  The parser 
just sees a stream of bytes that it interprets properly; the lower layer 
code should be doing the folding/unfolding magic transparently.

Id say this is one time that John and I are in 100% agreement for a 
change.. . :^)

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Tue, 27 Nov 2001 19:49:01 -0500

Shannon wrote on 11/27/2001 04:58:26 PM:
> (and perhaps to also define what an "octet" is...)

Just reference RFC 760 / STD 5 (Internet Protocol).  Its defined in that 
RFCs glossary (and a 'standard' now).

Bruce

---

From: "John Stracke" <[email-masked]>
Date: Wed, 28 Nov 2001 09:54:18 -0500

change.. . :^) 

Yeah, but we could probably find a way to disagree about it if we tried. 
:-)

/=======================================================\
|John Stracke                   |Principal Engineer     |
[email-masked]  |Incentive Systems, Inc.|
|http://www.incentivesystems.com|My opinions are my own.|
|=======================================================|
|Never do card tricks for your poker buddies.           |
\=======================================================/

---

From: [email-masked]
Date: Thu, 29 Nov 2001 10:53:03 -0500

Doug shot back on 11/28/2001 07:09:50 PM:
>    If you were to break apart the sequence 'AB' in this
>    factious multi and variable byte charset:
> 
>    If the (factious) multi byte two octet sequence for the letter
>    'A' (in hex):
> 
>       8A 0C
> 
>    And the (factious) 'B' were:
> 
>       8A 0D
> 
> 
>    And you wrap (8A 0C 8A 0D) in the middle with a CR (OC) and a
>    newline (OD) followed by a space (20), it would look like:
> 
>       8A 0C 0D 20 0C 8A 0D
> 
>    It would see the stream as:
> 
>       'A' newline space CR 'B'
> 
>    And NOT:
> 
>       'A' newline CR space 'B'
> 
> BUSTED!

Not Busted!  Thats an incorrect example of folding.  From 2445, Section 
4.1 Content Lines:

                                                     That is, a long
   line can be split between any two characters by inserting a CRLF
   immediately followed by a single linear white space character (i.e.,
   SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence
   of CRLF followed immediately by a single linear white space character
   is ignored (i.e., removed) when processing the content type.

so properly splitting your factious example it would become:

        8A 0D 0A 20 0C 8A 0D

which would look like:

        'B' LF space FF 'B'

_if_ you just took the raw stream at face value.  However the un/folding 
should be handled before parsing (but you CAN do it concurently if you are 
BIG GLUTTON for punishment).  As such, if you actually followed the last 
line cited above then your code SHOULD be converting:

        8A 0D 0A 20 0C 8A 0D

(back) to the expected:

        8A 0C 8A 0D

"when processing the content type".  Un/folding should be done before 
attempting to match character content but Im not going to say someone has 
to do it; let 'em take the harder path if they really want to.  I took 
that path on my first iCalendar parser and quickly realized the error of 
my ways... 

Shannon:  Add an issue to the iCalendar list to change the use of "two 
characters" in the 1st sentence above since we only care about octets as 
initially noted in the 1st line of the paragraph cited above:

   Lines of text SHOULD NOT be longer than 75 octets, excluding the line
   break.

Bruce

---

From: "John Stracke" <[email-masked]>
Date: Fri, 30 Nov 2001 16:23:43 -0500

>If you don't know the charset, you can't always tell how to put it
>back together.

You're right.  The problem I didn't see before is that, in a 2-byte 
character set, you might have the characters 0D0A 2041, which, to 
something built for ASCII, would look like CR LF SP A; the CR LF SP would 
then get dropped.

I think this complicates the story for senders; they need to split lines 
at the 75-octet mark, but the code that splits the lines only sees 
characters, not octets.  You said that splitting lines was only for 
presentation (does anybody disagree?); if so, we can change "75 octets" to 
"75 characters".

Make sense?

/=========================================================\
|John Stracke                   |Principal Engineer       |
[email-masked]  |Incentive Systems, Inc.  |
|http://www.incentivesystems.com|My opinions are my own.  |
|=========================================================|
|NT's lack of reliability is only surpassed by its lack of|
|scalability. --John Kirch                                |
\=========================================================/