[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-pkix-logotypes-06.txt
Tom,
This is an answer to the first argument raised.
> Denis, Russ:
>
> One reason why audio might be desired would be to allow the nearest
> available equivalent to logotype functionality. This might be motivated by
> one of several pieces of US legislation (the Americans with Disabilities
> Act and Section 508). If this is the case, the specification should
> probably reflect that audio is a backup, especially for individuals who
> cannot benefit from video.
One of the key issue is to understand the properties that a client compliant
with this specification must support. Currently we have:
"Compliant applications MUST display more just one (or none) of the images
*and* play just one (or none) of the audio sequences at the same time."
The *AND* is not acceptable.
First of all, if audio is going to be supported, then separate requirements
should be made so that client compliant with requirements fo image
representation, can ignore compliance requirements for audio representation.
Now, do we want to promote the use of gingles for VISA, AMEX, MasterCard ?
They would need to invent them.
If a user using a client is blind, do we think he will be more confident by
hearing the gingle ? How does he make sure that the gingle really originates
from the logoype extension ?
> I have a couple of suggestions in that case:
> The image component should be mandatory, while other components
> should be optional
> Clients should be directed to use other components only when the use
> of the video component is known to be impractical or useless, or the user
> has explicitly selected the other component.
While your formulation sound reasonable, I am still questioning the need
to support audio.
Denis
> Tom Gindin
>
> Denis Pinkas <Denis.Pinkas@xxxxxxxx>@mail.imc.org on 10/15/2002 03:46:34 AM
>
> Sent by: owner-ietf-pkix@xxxxxxxxxxxx
>
> To: "Housley, Russ" <rhousley@xxxxxxxxxxxxxxx>
> cc: ietf-pkix@xxxxxxx
> Subject: Re: draft-ietf-pkix-logotypes-06.txt
>
> Russ,
>
> > We just posted an update to the logotypes draft. There are two primary
> > changes from the previous version. First, we tried to be more clear
> about
> > what is mandatory to implement and what is not.
>
> This is not yet clear enough. See below.
>
> > Second, we added support for more than one hash function without having
> > to repeat a lot of data.
> >
> > The loudest objections (as opposed to jokes) came from Microsoft. Based
> on
> > discussions with Trevor Freeman, I believe that Microsoft can accept this
> > version.
> >
> > We are still in Working Group Last Call.....
>
> 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.
>
> 2. Page 7. Section 4.1 Extension format
>
> "Clients MUST support both direct and indirect addressing."
>
> I disagree. If an end-user certificate is included in a signature, it may
> be
> interesting to display the logotype even if the terminal is off-line.
> Indirect addressing would mandate an on-line connection.
>
> Replace with:
>
> "Clients claiming to conform with this document SHALL support direct
> addressing. Clients MAY also support indirect addressing."
>
> 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".
>
> 4. Page 8. Section 4.1.
>
> LogotypeData ::= SEQUENCE {
> image SEQUENCE OF LogotypeImage OPTIONAL,
> audio [1] SEQUENCE OF LogotypeAudio OPTIONAL }
>
> Since audio support should be suppressed, replace with:
>
> LogotypeData ::= SEQUENCE OF LogotypeImage
>
> 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.
>
> The ASN.1 structure is not adapted to make that difference. Therefore it is
> proposed to modify the ASN.1 syntax along the following way:
>
> communityLogos [0] EXPLICIT CommunityLogos OPTIONAL,
>
> CommunityLogos ::= SEQUENCE OF CommunityLogo
>
> CommunityLogo ::= LogotypeInfo
>
> In this way, clients can make their best efforts to support only one
> instance of version for each CommunityLogo.
>
> 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 ???
>
> 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."
>
> 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 ?
>
> 9. Page 9. Section 4.1. Since audio is a joke, text and ASN.1 about audio
> should be deleted.
>
> 10. Page 9. Section 4.1. The text states:
>
> "Implementations MUST support both the JPEG and GIF image formats (with
> MIME
> types of "image/jpeg" and "image/gif", respectively)"
>
> I would guess that Animated GIF should not be supported. Could we say it ?
>
> 11. Page 10. Section 4.1.
>
> Community Logotype. If communityLogo is present, the logotype MUST
> represent the community to which the certificate issuer is
> affiliated. The communityLogo MAY be present in an end entity
> certificate, a CA certificate or an attribute certificate.
>
> A certificate issuer may belong to more than one community. Replace: "the
> community " by :"the community or the communities".
>
> 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".
>
> Denis
>
> >
> > Russ