Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-02.txt

From: "Housley, Russ" <[email-masked]>
Date: Thu, 16 May 2002 11:17:03 -0400

James:

I have been giving this issue (raised almost a month ago) some 
thought.  Suppose that an community wants to make their logo available in 
many different formats to support the diverse set of platforms that may 
choose to display it.  A credit card brand logo is a straightforward 
example.  The logo might be displayed on a desktop machine, a laptop, a 
kiosk, a palm device, or a cell phone.  Each has a different environment, 
display resolution, color resolution, and so on.  Therefore, I think the 
application needs to know what image formats are available.

You make the point that the file extension does not really have to be 
honored.  It is followed by convention, but that the MIME type really 
governs way that the URL will be processed.

To me, the question is what provides the application with the best selector 
to pick the URL.  If the blob of bits that is returned is not in the 
expected format, then the application may not be able to display 
anything.  The result will be an empty box instead of a logo.  Since this 
is bad for the community, I expect them to follow any conventions that we 
establish.

Is a file extension or a longer MIME type a better convention?  I think 
that they provide the same information as a selector.  I advocate the file 
extension.  I have only one reason -- it is shorter.

Russ

At 11:52 AM 4/19/2002 +1000, Manger, James H wrote:

>A referenced logo WILL be identified by a MIME-type.  Dereferencing the URI
>will (presumably) result in something like the following (with various other
>header fields omitted):
>
>         HTTP/1.1 200 OK
>         Content-Length: 177
>         Last-Modified: Thu, 18 Sep 1997 04:22:02 GMT
>         Content-Type: image/gif
>
>         GIF89aJH&^%&^b6TB^(&...
>
>A ".gif" extension in the URL may suggest a "image/gif" MIME-type will be
>returned, but a web server is actually free to return any MIME-type it
>wants.  I think browsers will (and should) process the result based on the
>MIME-type instead of the URI extension.
>
>So perhaps it would be better for the 'imageFileExtn' field to be
>'imageContentType' and hold a MIME-type.  (might you ever what to include
>other MIME header fields? in which case a 'imageMIMEHeaders' field might be
>needed instead.)
>
>
>There is no description of the 'logotypeHash' field.  I suspect the authors
>intention is to hash the bytes of the *.gif (or *.jpeg) file, excluding any
>MIME or HTTP headers fields delivered with the image.  Presumably any
>transfer encoding (but not Content-Encoding?) is also removed before
>hashing?
>
>Such a hash does not bind the content to the MIME-type.  This maybe
>acceptable, though it might warrant a paragraph in the security
>considerations section.
>
>
>Change the 'highRes' and 'lowRes' field names to, say, 'reference' and
>'embedded' (or 'indirect' and 'direct').  Which resolutions are appropriate
>is a matter of judgement, policy, environment or best practise -- so it
>should be discussed in the document, but not hard-wired into the syntax.
>
>
>
> > ----------
> > From: Housley, Russ [SMTP:[email-masked]]
> > Sent: Friday, 19 April 2002 5:58 am
> >
> > >..Also, IMHO it would be better to identify GIF & JPEG pictures by their
> > >corresponding MIME types than to invent your own way of doing this..
> >
>         ..We do not want to point to a MIME encoded object.  Rather we want
>to point
> > to the GIF or JPEG binary object.  In this manner, one could use the same
> > file for many different purposes, including display on the organization's
> > web page.  This size seems appropriate for a logo in a header.
> >

---

From: Dean Povey <[email-masked]>
Date: Fri, 17 May 2002 15:10:23 +1000

>extension.  I have only one reason -- it is shorter.

Um, compared to putting embedded images in a cert this is irrelevant. The
MIME type is a (more or less) managed namespace without ambiguity.  I think
the benefits of choosing the MIME type rather than the file extension to
indicate the image format are clear.

-- 
Dean Povey,              |em: [email-masked] |  JCSI: Java security toolkit
Senior S/W Developer     |ph:  +61 7 3023 5139    | uPKI: Embedded/C PKI toolkit
Wedgetail Communications |fax: +61 7 3864 1282    | uSSL: Embedded/C SSL toolkit
Brisbane, Australia      |www: www.wedgetail.com  | XML Security: XML Signatures