RE: New draft-ietf-pkix-logotypes-08.txt

["Stefan Santesson" <stefan@xxxxxxxxxxxx>]

Denis,

Most of the issues are already handled in the document. See comments below.

Regarding sizes, we may consider providing some guidance regarding the sizes
to be expected. This should thus not be requirements for conformance, but
rather just guidance for implementers.

> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> Sent: Tuesday, November 19, 2002 11:38 AM
> To: ietf-pkix@xxxxxxx
> Cc: Stefan Santesson; Housley, Russ; Trevor Freeman
> Subject: Re: New draft-ietf-pkix-logotypes-08.txt
>
>
> > There is a new logotypes draft 08 available from:
> >
> > http://www.addtrust.com/pub/logotypes-08_dr03.txt
> > or from:
> >
> ftp://ftp.rsasecurity.com/pub/rsalabs/tmp/draft-ietf-pkix-logotypes-08.txt
> >
> > This draft support inclusion of multiple community logos.
> > There is still support for audio.
> >
> > It is the authors view that this reflects the rough consensus
> of this list
> > and that it take care of the comments raised during WG last call.
>
> The following comments that have ben raised during the last call have not
> been solved:
>
> 3. Page 7. Section 4.1 Extension format
>
> There is no text which states what the client should do whenever it is
> unable to support a given logotype. Insert the following text:
>
>   "Whenever a client is unable to support a given logotype, no
> error SHALL be
>   reported and the client MUST behave as if there was no logotype
> included in
>   the certificate".
>

This is covered in section 6 (use in clients)

Current texts says:
   "If client is unable to support a provided logotype, the client
   MUST NOT report an error, rather the client MUST behave as though no
   logotype extension was included in the certificate."


> This raises the point that section 3 is still incorrect:
>
>     "This specification defines two types of logotype data: image data and
>     audio data. Implementations MUST support image data; however, support
>     for audio data is OPTIONAL."
>
> There are no implementations that MUST support image data, since
> display is
> optional. However, we should define what is a client *capable of*
> displaying
> logotypes. We currently can't since comment 7 has not been addressed.
>

This is also covered in section 6.

Current text says:
   "A client MAY, subject to local policy, choose to display none, one or
   any number of the logotypes in the logotype extension."

> In the same way since it seems that this (?!?!) audio logotype is
> likely to
> stay, we should define what is a client capable of playing a logotype.
>
> Proposed text:
>
>     This specification defines two types of logotype data: image data and
>     audio data. Implementations claiming conformance with this document
>     MUST be able to support image data with some minimum caracteristics;
>     however, they MAY also be able to support audio data, with some
>     minimum caracteristics."
>

This says the same thing as the text in the beginning of section 3, except
for your wording "minimum characteristics", where we simply disagree that
this is appropriate wording, since the implementation has to accommodate the
display characteristics of the device it is running on.

> It is also proposed to add that key sentence to the abstract, which is
> currently too short:
>
>     This document specifies a certificate extension for including
>     logotypes in public key certificates and attribute certificates.
>

We think the abstract is fine, in any way we can't place requirements in the
abstract.

> 7. Page 9. Section 4.1.
>
>         LogotypeImageInfo ::= SEQUENCE {
>            fileSize        INTEGER,  -- In octets
>            xSize           INTEGER,  -- In pixels
>            ySize           INTEGER,  -- In pixels
>            numColors       INTEGER } -- In bits
>
>   It is of particular importance to say what means conformance to this
>   document for a client with respect to the number of pixels to
> support and
>   the colors to support.
>
>   It is proposed to add a sentence along these lines:
>
>   "Clients claiming to conform with this document SHALL support
> an image with
>   a minimum size of 48 pixels (xSize) by 32 pixels (ySize) in
> black and white
>   with X grey levels."

This is addressed at the beginning of this mail.

/Stefan & Trevor

>
> Denis
>
> > This draft, or an agreed update to this draft, will be posted
> to ID directly
> > after the Atlanta meeting.
> >
> > /Stefan
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: owner-ietf-pkix@xxxxxxxxxxxx
> >>[mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Housley, Russ
> >>Sent: Tuesday, October 29, 2002 3:17 PM
> >>To: ietf-pkix@xxxxxxx
> >>Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-07.txt
> >>
> >>
> >>
> >>This update captures the things that have agreed.  The biggest change is
> >>the support in the syntax for color and gray scale images.  Many other
> >>little changes are included.
> >>
> >>As I see it, there are two open issues:
> >>    1) Removal of audio; and
> >>    2) Support for more than one logotype in each of the categories
> >>
> >>These two topics are still being discussed on the list.
> >>
> >>Russ
> >>
> >>
> >>>        Title           : Internet X.509 Public Key Infrastructure:
> >>>Logotypes in
> >>>                          X.509 certificates
> >>>        Author(s)       : S. Santesson, R. Housley, T. Freeman
> >>>        Filename        : draft-ietf-pkix-logotypes-07.txt
> >>>        Pages           : 21
> >>>        Date            : 2002-10-28
> >>
> >
> >
>
>
>