[ticker-dev] Why Attachment field as byte array?

[David Arnold]

-->"j" == j  <j at pobox.com> writes:

  j> The Attachment field in the latest ticker spec (3.0) is defined
  j> as a byte array.

yep.

  j> Note that this field is an opaque type, and thus an array of
  j> bytes.  therefore, it is not necessary to transform attachments
  j> (using, for example, base64) as is the usual practice for email.

in other words, you are free to use 8bit encoding, and there is no
need for base64 or any other mechanism to ensure the entire object is
7bit clean.

  j> However, it is also MIME encoded. 

the MIME encoding is used to describe the type of the enclosed
object(s) in a way that it was hoped would be reasonably portable.  it
also allows for transparent attachment of multiple objects.

  j> Given that MIME is intended to support sending binary information
  j> as text, is there any reason I am missing why the Attachment
  j> filed should not be defined as being a string?

this was the hardest choice.  

opaque has some forcing function for attachment vs. content, which
highlights the blurring between these roles in current practice.

opaque removes the need to use base64 (or other) encoding for content
data.

string means that everything has to be 7bit clean (or it risks
collision with UTF-8 rules).

string allows matching over the MIME *headers*, using
contains()/wildcard()/regex().  this maintains the blurring between
content and attachment we currently have.

allowing matching over attachment fields is potentially expensive,
performance-wise, when attachments could be quite large.

  j> For instance, if an application receives and Attachment in a
  j> notif, how does it determine if its a MIME string, or a binary
  j> JPEG?  Or is that just part of the magic MIME handlers are
  j> expected to cope with?

it MUST be a MIME object.  to attachment a JPEG, the image data needs
to be wrapped in MIME headers, something like

  MIME-Version: 1.0
  Content-Type: image/jpeg; name="pr0n.jpg"
  Content-Disposition: attachment; name="pr0n.jog"
  Content-Transfer-Encoding: 8bit
  
  < image data >

it it not legal to attach plain content (without MIME headers).




d