[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-ietf-pkix-logotypes-06.txt
Russ,
I agree to everything you suggest here.
Speaking about different image formats options, I still wonder, and would
like input from implementers, if it would be worth the effort to
define/recommend some standard sizes. Some part of me believe this would
increase interoperability and as Issuer of certificates it would make life
easier for me If I have some hints about what clients may expect for optimal
performance.
But maybe this is a post-standard task for another fora?
/Stefan
> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Housley, Russ
> Sent: Friday, October 25, 2002 5:45 PM
> To: Denis Pinkas
> Cc: ietf-pkix@xxxxxxx
> Subject: Re: draft-ietf-pkix-logotypes-06.txt
>
>
>
> Denis:
>
> I have deleted portions of the growing message thread where we appear to
> have reached agreement. Hopefully, this will allow us to focus on the
> remaining areas of disagreement.
>
> >>>Since we are still in Working Group Last Call, here are my 12
> comments on
> >>>that document.
> >>>
> >>>1. Page 6. Section 3. Logotype data
> >>>
> >>>"Implementations MUST support image data; however, support for
> audio data is
> >>>OPTIONAL." Audio is a good joke, in the same way, as pheromones. We are
> >>>supposed to deal with serious documents. Please delete.
> >>
> >>I belive that the response from Tom Gindin shows that there is support
> >>for audio in support if disabled users. I believe that the document is
> >>clear that the support is OPTIONAL.
> >
> >The document was not clear that the support is OPTIONAL. There is still
> >much controversy about the need for it. No convincing arguments
> have been
> >provided. Please delete or make a strawpoll.
>
> The first paragraph in section 3 says:
>
> 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.
>
> What is unclear?
>
>
> >>>5. Page 7. Section 4.1.
> >>>
> >>>We have:
> >>>
> >>> communityLogo [0] EXPLICIT LogotypeInfo OPTIONAL,
> >>>
> >>> LogotypeInfo ::= CHOICE {
> >>> direct [0] LogotypeData,
> >>> indirect [1] LogotypeReference }
> >>>
> >>> LogotypeData ::= SEQUENCE {
> >>> image SEQUENCE OF LogotypeImage OPTIONAL,
> >>>
> >>>No explanations are given on the text about what to do for a
> client when
> >>>there is more than one LogotypeImage present in a communityLogo.
> >>>
> >>>First of all, a communityLogo may contain more than one logo
> which belongs
> >>>to one or more communities. However the client has no way to
> know whether
> >>>the LogotypeData includes different versions from the same
> logo (e.g. in
> >>>black and white or in color) or different logos.
> >>
> >>This is not supported. The certificate may only include one image.
> >>That image could be a composite of many different logos, if
> >>appropriate. We discussed this face-to-face in Yokohama. Discussion
> >>with people what develop graphical interfaces do not think it is a good
> >>idea to allow this complexity. Too many images will confuse the user.
> >
> >>When it is appropriate to include several community logos, they must be
> >>combined into one image to ensure that they are consistently displayed.
> >>If this is not done, each client will render the images differently...
> >
> >We still have different views on that topic, which is far more important
> >than audio. To give a parallel: some banks are members of both VISA and
> >EuroCard. Transposed into certificates, this may mean two logos. In the
> >same way, a CA may be certifed by two laboratories. The logo of
> these two
> >laboratories may be displayed.
> >
> >So for community certificates, I am requesting the possibility to have
> >more than one logo. The use of combined logos is not appropraite
> to solve
> >this issue.
>
> I do not believe that we can support this without creating significant
> confusion. However, it is simple and straightforward for a CA to
> generate
> an image file that contains a combination of logos. This is the only way
> that I can see where the combined logo is consistently displayed.
> If it is
> not consistent, then we have not helped the use make a selection from a
> group of certificates without investigating details.
>
>
> >>>6. Page 9. Section 4.1.
> >>>
> >>> LogotypeImageInfo ::= SEQUENCE {
> >>> fileSize INTEGER, -- In octets
> >>> xSize INTEGER, -- In pixels
> >>> ySize INTEGER, -- In pixels
> >>> numColors INTEGER } -- In bits
> >>>
> >>>Text is missing to explain this structure. How is a grey scale
> indicated for
> >>>jpeg and for gif ???
> >>
> >>Do you have a recommendation?
> >
> >No. But I wonder whether the structure is correct. Has it been
> verifed by
> >an image expert ? Many PDAs have B&N screens only because they
> are cheaper.
>
> It was generated from documents that describe image formats. You may be
> correct that a CHOICE is needed with one branch for color images and
> another branch for grey scale. I will do some further investigation.
>
>
> >>>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."
> >>
> >>We have tried to avoid such a statement. Instead we allow the
> inclusion
> >>of the same image at many different resolutions so that the client can
> >>select the best fit. This is also the reason that we use MIME types to
> >>name the format. It allows the greatest flexibility.
> >
> > ... but is does not provide any conformance clause.
> >
> >Can we say that a client is logo-enabled if it only supports 10 x 10
> >pixels ? Unless the minimumm size (whatever it is) is always present in
> >the logo, then it is not possible to say that the client is logo-enabled.
>
> I would like to hear from developers on this one.
>
>
> >>>8. Page 9. Section 4.1.
> >>>
> >>> LogotypeImageInfo ::= SEQUENCE {
> >>> fileSize INTEGER, -- In octets
> >>> xSize INTEGER, -- In pixels
> >>> ySize INTEGER, -- In pixels
> >>> numColors INTEGER } -- In bits
> >>>
> >>>It would also be appropriate to say what to do when the image
> is in color
> >>>and that the client has no color display available. No display at all ?
> >>>Conversion into grey scale using which kind of transposition ?
> >>
> >>The client is always allowed to ignore the logotype altogether. The
> >>stronger language added in response to your third comment makes
> this clear.
> >
> >Do you mean that if the logo is defined in color and the
> terminal is only
> >B&N then the logo shall not be displayed ? If so, this should be
> clearly said.
>
> To make such a statement, we need to implement the color vs. grey scale
> CHOICE that I described earlier. I will do further investigation.
>
>
> >>>12. Page 11. Section 5. Type of certificates
> >>>
> >>> Logotypes MAY be present in three types of certificates:
> >>>
> >>> - CA certificates
> >>> - End-entity certificates
> >>> - Attribute certificates
> >>>
> >>>Why is there such a limitation ? CRL Issuers, OCSP responders
> or TSUs may
> >>>have logotypes present in their certificates.
> >>>
> >>>Replace with : "Logotypes MAY be present in any type of certificate".
> >>
> >>David Cross spoke against this suggestion.
> >
> >No. David Croos spoke about the *display* of the logo, not the
> *presence*
> >of the logo. Please make the change or provide new arguments.
>
> I propose a complete rewrite of section 5:
>
> 5. Type of certificates
>
> Logotypes MAY included in public key certificates and attribute
> certificates at the discretion of the certificate issuer; however;
> logotypes MUST NOT be part of certification path validation or any
> type of automated processing. The sole purpose of logotypes is to
> enhance display of a particular certificate, regardless of its
> position in a certification path.
>
> Russ
>