Thread Subject: Re: Comments re: duplication of requirements indifferent sections

Return to this mailing list's archives

From: Michaelis, Paul R. (Paul)
Date: Tue, Mar 06 2007 7:20 AM
Subject: Re: Comments re: duplication of requirements indifferent sections

I agree completely with what Tom has said. I cannot ensure conformance
if I cannot point my telecom engineers and product managers to a single,
complete list of the requirements that apply to their products. It's
silly to burden them with an additional requirement that they use the
Buy Accessible Wizard to see what applies. (BTW, as a separate issues,
the Wizard does not always provide sensible recommendations...) If this
means that some of the requirements will continue to be duplicated in
different sections, this is a very small price to pay in exchange for
ease-of-use and greater likelihood of conformance.

-- Paul Michaelis



I don't understand why some people think it's a problem if requirements
are duplicated in different sections.

-----Original Message-----
From: Tom Brett [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, March 06, 2007 2:48 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] Comments re: the proposed revisionsto
1194.23(k)

I do not agree. Many developers or requiring officials will state that
if the provision is not listed for the category of product that I am
working on then the provision does not apply. This has occurred many
times in the past. While not duplicating the provisions would seem to
be the most efficient way to show the provisions for knowledgeable
individuals, these standards should be written for those who only have a
passing interest or need. When the supervisor directs the Grade 4 clerk
to purchase a EIT item, the clerk is going to take the path of least
resistance. Not all agencies use the GSA Buy Accessible Wizard that
would enumerate the standards & provisions and there needs to be a
comprehensive list of standards/provisions that someone can look at to
evaluate the conformance of the product.

Tom Brett


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Tuesday, March 06, 2007 12:41 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] Comments re: the proposed revisionsto
1194.23(k)

Everything in the hardware section would apply to telecom that is
hardware.
So you don't need to duplicate them.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Debbie
> Cook
> Sent: Monday, March 05, 2007 2:40 PM
> To: TEITAC Telecommunications Subcommittee
> Subject: Re: [teitac-telecom] Comments re: the proposed revisions to
> 1194.23(k)
>
> K-1, K-1, and K-3 are appropriately hardware requirements. We did
> discuss coverage of them In Closed, but this was prior to the
> expansion of the desktop group to include all hardware.
> K-4 is interesting. It's a software function, but as Paul points out
> it's a software function very specific to telecomm and as such should
> probably be addressed and retained in this group.
> ----- Original Message -----
> From: "Michaelis, Paul R. (Paul)" < = EMAIL ADDRESS REMOVED = >
> To: < = EMAIL ADDRESS REMOVED = >
> Sent: Sunday, March 04, 2007 3:22 PM
> Subject: [teitac-telecom] Comments re: the proposed revisions to
> 1194.23(k)
>
>
> It has been proposed that we move all four of the requirements under
> 1194.23(k) to Closed Products. I'm quite comfortable with the idea of

> moving 1194.23(k)(1), (k)(2), and (k)(3), chiefly because I don't
> think I've ever seen a phone that violates these requirements.
> 1194.23(k)(4) is a different matter.
> I'm worried that moving it, without providing a suitable replacement
> within the telecom section, is likely to cause a tremendously
> important telecom accessibility function to be ignored by vendors and
> by procurement officials.
>
>
>
> 1194.23(k)(4) says the following: "The status of all locking or toggle

> controls or keys shall be visually discernible, and discernible either

> through touch or sound." Okay, so what's the relevance to telecom?
>
>
>
> Telephones of the sort commonly acquired by businesses and by
> government agencies tend to present a tremendous amount of information

> visually.
> In addition to caller ID, the visually presented information often
> includes which lines are in use, which are on hold, whether there is
> new voicemail, whether the phone is forwarded, whether "do not
> disturb" is active, whether someone on hold has disconnected, and so
> on.
> Job-specific information is also presented; for example, when used in
> a contact center environment, the phones will display information such

> as the number of calls in queue, the mean waiting time for callers on
> hold,
> and the agent's "split assignment." In fact, in Avaya systems, the
> status of over 240 different telephony functions may be displayed
> visually by the telephone.
>
>
>
> I have always interpreted 1194.23(k)(4) to mean that, if a telephone
> is able to display information or the status of a function visually,
> it must be possible for a blind or visually impaired user of that
> telephone
> to obtain the same information via a non-visual mechanism. Going
> forward, I believe that we must have an explicit statement within the
> telecom section, requiring physical telephones to provide the same
> information to visually impaired users that is provided to sighted
> users. Without such a requirement, all but the simplest functions
> provided by modern telephones will be inaccessible to users who cannot

> see the telephones' displays.
>
>
>
> I propose the following wording, as a way to retain a requirement
> similar to 1194.23(k)(4) in the telecom section:
> "All of the information that is presented visually by a telephone must

> be available via a non-visual mechanism to blind or visually impaired
> users of that telephone."
>
>
>
> Regards,
>
>
>
> Paul Michaelis
>
>
>
>
> --------------------------------------------------------------
> ------------------
>
>
>

From: Jim Tobias
Date: Tue, Mar 06 2007 8:45 AM
Subject: Re: Comments re: duplication of requirementsindifferent sections

I think the duplication of requirements issue depends on how many times
things are duplicated.
A 20 page document without duplication is more usable than a 100 page
document with lots of
duplication. An indexing section could clearly and authoritatively say
which provisions
apply to which product types or feature types.

Secondly, when people first encounter this information they need to *learn*;
the principles
of accessibility need to be available, using some sort of thematic
consistency like "all
hardware products with mechanical controls". Do we need to worry about
first-timers and learners?
Yes. Consider the staff churn in most companies. Consider also that
success will be measured
by how effectively 255/508 can be bureaucratized, meaning you don't have to
be a full-time
expert to work on accessibility. Most of the accessibility work should be
done by people for
whom it is only 2-5% of their job, and that means clarity and easy learning.

Thirdly, how many pracxtitioners in companies use the current standards just
as they are, in a flat
plain text document? I think most have created websites with lots of links
to their products, additional guidance, training materials, etc. Terry
mentioned the idea of having a "Build Accessible Wizard"
to correlate with the material in the Buy Accessible Wizard. Whether or not
each company would use
it as is, it would make a great template for matching product types with
provisions.

******
Jim Tobias
Inclusive Technologies
= EMAIL ADDRESS REMOVED =
+1 732.441.0831 voice/tty
skype jimtobias
+1 908.907.2387 mobile

> -----Original Message-----
> From: Michaelis, Paul R. (Paul) [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Tuesday, March 06, 2007 9:16 AM
> To: TEITAC Telecommunications Subcommittee
> Subject: Re: [teitac-telecom] Comments re: duplication of
> requirements indifferent sections
>
> I agree completely with what Tom has said. I cannot ensure
> conformance if I cannot point my telecom engineers and
> product managers to a single, complete list of the
> requirements that apply to their products. It's silly to
> burden them with an additional requirement that they use the
> Buy Accessible Wizard to see what applies. (BTW, as a
> separate issues, the Wizard does not always provide sensible
> recommendations...) If this means that some of the
> requirements will continue to be duplicated in different
> sections, this is a very small price to pay in exchange for
> ease-of-use and greater likelihood of conformance.
>
> -- Paul Michaelis
>
>
>
> I don't understand why some people think it's a problem if
> requirements are duplicated in different sections.
>
> -----Original Message-----
> From: Tom Brett [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Tuesday, March 06, 2007 2:48 AM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] Comments re: the proposed revisionsto
> 1194.23(k)
>
> I do not agree. Many developers or requiring officials will
> state that if the provision is not listed for the category of
> product that I am working on then the provision does not
> apply. This has occurred many times in the past. While not
> duplicating the provisions would seem to be the most
> efficient way to show the provisions for knowledgeable
> individuals, these standards should be written for those who
> only have a passing interest or need. When the supervisor
> directs the Grade 4 clerk to purchase a EIT item, the clerk
> is going to take the path of least resistance. Not all
> agencies use the GSA Buy Accessible Wizard that would
> enumerate the standards & provisions and there needs to be a
> comprehensive list of standards/provisions that someone can
> look at to evaluate the conformance of the product.
>
> Tom Brett
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Gregg Vanderheiden
> Sent: Tuesday, March 06, 2007 12:41 AM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] Comments re: the proposed revisionsto
> 1194.23(k)
>
> Everything in the hardware section would apply to telecom
> that is hardware.
> So you don't need to duplicate them.
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Debbie
> > Cook
> > Sent: Monday, March 05, 2007 2:40 PM
> > To: TEITAC Telecommunications Subcommittee
> > Subject: Re: [teitac-telecom] Comments re: the proposed revisions to
> > 1194.23(k)
> >
> > K-1, K-1, and K-3 are appropriately hardware requirements. We did
> > discuss coverage of them In Closed, but this was prior to the
> > expansion of the desktop group to include all hardware.
> > K-4 is interesting. It's a software function, but as Paul
> points out
> > it's a software function very specific to telecomm and as
> such should
> > probably be addressed and retained in this group.
> > ----- Original Message -----
> > From: "Michaelis, Paul R. (Paul)" < = EMAIL ADDRESS REMOVED = >
> > To: < = EMAIL ADDRESS REMOVED = >
> > Sent: Sunday, March 04, 2007 3:22 PM
> > Subject: [teitac-telecom] Comments re: the proposed revisions to
> > 1194.23(k)
> >
> >
> > It has been proposed that we move all four of the requirements under
> > 1194.23(k) to Closed Products. I'm quite comfortable with
> the idea of
>
> > moving 1194.23(k)(1), (k)(2), and (k)(3), chiefly because I don't
> > think I've ever seen a phone that violates these requirements.
> > 1194.23(k)(4) is a different matter.
> > I'm worried that moving it, without providing a suitable
> replacement
> > within the telecom section, is likely to cause a tremendously
> > important telecom accessibility function to be ignored by
> vendors and
> > by procurement officials.
> >
> >
> >
> > 1194.23(k)(4) says the following: "The status of all
> locking or toggle
>
> > controls or keys shall be visually discernible, and
> discernible either
>
> > through touch or sound." Okay, so what's the relevance to telecom?
> >
> >
> >
> > Telephones of the sort commonly acquired by businesses and by
> > government agencies tend to present a tremendous amount of
> information
>
> > visually.
> > In addition to caller ID, the visually presented information often
> > includes which lines are in use, which are on hold, whether
> there is
> > new voicemail, whether the phone is forwarded, whether "do not
> > disturb" is active, whether someone on hold has
> disconnected, and so
> > on.
> > Job-specific information is also presented; for example,
> when used in
> > a contact center environment, the phones will display
> information such
>
> > as the number of calls in queue, the mean waiting time for
> callers on
> > hold,
> > and the agent's "split assignment." In fact, in Avaya systems, the
> > status of over 240 different telephony functions may be displayed
> > visually by the telephone.
> >
> >
> >
> > I have always interpreted 1194.23(k)(4) to mean that, if a
> telephone
> > is able to display information or the status of a function
> visually,
> > it must be possible for a blind or visually impaired user of that
> > telephone
> > to obtain the same information via a non-visual mechanism. Going
> > forward, I believe that we must have an explicit statement
> within the
> > telecom section, requiring physical telephones to provide the same
> > information to visually impaired users that is provided to sighted
> > users. Without such a requirement, all but the simplest functions
> > provided by modern telephones will be inaccessible to users
> who cannot
>
> > see the telephones' displays.
> >
> >
> >
> > I propose the following wording, as a way to retain a requirement
> > similar to 1194.23(k)(4) in the telecom section:
> > "All of the information that is presented visually by a
> telephone must
>
> > be available via a non-visual mechanism to blind or
> visually impaired
> > users of that telephone."
> >
> >
> >
> > Regards,
> >
> >
> >
> > Paul Michaelis
> >
> >
> >
> >
> > --------------------------------------------------------------
> > ------------------
> >
> >
> >

From: terry.weaver@gsa.gov
Date: Tue, Mar 06 2007 9:30 AM
Subject: Re: Comments re: duplication of requirements in different sections

To address the point of a comprehensive list - there is one; it is the
Standard itself. The only utility provided by the categories that the
provisions are grouped under (software applications and operating systems,
web-based intranet and internet information and applications,
telecommunications products, video and multimedia, self contained, closed
products and desktop and portable computers) is ease of understanding by
providing a mental image of what the provisions that followed most likely
pertained to. The categories were problematic from day one because we
already had products that bridged categories (think smart phones and
all-in-one printers). The Standards addressed this by the very first
sentence in 1194.2 Application "(a) Products covered by this part shall
comply with all applicable provisions of this part." No mention at all of
the category as a delimitator.

The Access Board has been steadfast in its position that the existing
provisions not be distilled down into an easy to use/ understand list
because they felt that was the intention of the Standard itself. We can
decide to simplify this in the refresh activities, but getting agreement
on shorthand sentences are as difficult as coming to consensus on the full
text.

The problem with the approach that Paul and Tom suggest is that creating a
comprehensive list of provisions that apply to specific products is the
effort required to keep it updated. As a government buyer, I don't know
how we could do that even if we knew what was coming next as technology
advances. Since it has taken 7 years to update the first iteration of the
Standards, I wouldn't want to design a process that would require frequent
updates to make the Standard relevant to new innovations in technology.

Regarding the BAW: the intended use of the Buy Accessible Wizard is to
first and foremost ensure uniform compliance within the Federal
government's buying community. The provisions as written are not
understandable by the vast numbers of people who have to use them so the
Wizard has reverse engineered the provisions to the characteristics. To
make it understandable to the Fed buyer, the BAW asks a series of
questions that the buyer should know, such as will the product to be
purchased have a keyboard or will it connect to a system, etc. By design,
it incorporates as applicable as many provisions as possible so that it
doesn't inadvertently leave out something. And since this applicability
step is the lead in to the market research phase, that is appropriate. It
is clumsier for product engineers and designers but they aren't the
intended audience. It enables Fed buyers to refine their agency's
requirements by discovering what is available in the commercial market
place before the agency issues its RFP.






"Michaelis, Paul R. (Paul)" < = EMAIL ADDRESS REMOVED = >
Sent by: = EMAIL ADDRESS REMOVED =
03/06/2007 09:16 AM
Please respond to
"TEITAC Telecommunications Subcommittee" < = EMAIL ADDRESS REMOVED = >


To
"TEITAC Telecommunications Subcommittee" < = EMAIL ADDRESS REMOVED = >
cc

Subject
Re: [teitac-telecom] Comments re: duplication of requirements in different
sections






I agree completely with what Tom has said. I cannot ensure conformance
if I cannot point my telecom engineers and product managers to a single,
complete list of the requirements that apply to their products. It's
silly to burden them with an additional requirement that they use the
Buy Accessible Wizard to see what applies. (BTW, as a separate issues,
the Wizard does not always provide sensible recommendations...) If this
means that some of the requirements will continue to be duplicated in
different sections, this is a very small price to pay in exchange for
ease-of-use and greater likelihood of conformance.

-- Paul Michaelis



I don't understand why some people think it's a problem if requirements
are duplicated in different sections.

-----Original Message-----
From: Tom Brett [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, March 06, 2007 2:48 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] Comments re: the proposed revisionsto
1194.23(k)

I do not agree. Many developers or requiring officials will state that
if the provision is not listed for the category of product that I am
working on then the provision does not apply. This has occurred many
times in the past. While not duplicating the provisions would seem to
be the most efficient way to show the provisions for knowledgeable
individuals, these standards should be written for those who only have a
passing interest or need. When the supervisor directs the Grade 4 clerk
to purchase a EIT item, the clerk is going to take the path of least
resistance. Not all agencies use the GSA Buy Accessible Wizard that
would enumerate the standards & provisions and there needs to be a
comprehensive list of standards/provisions that someone can look at to
evaluate the conformance of the product.

Tom Brett


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Tuesday, March 06, 2007 12:41 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] Comments re: the proposed revisionsto
1194.23(k)

Everything in the hardware section would apply to telecom that is
hardware.
So you don't need to duplicate them.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Debbie
> Cook
> Sent: Monday, March 05, 2007 2:40 PM
> To: TEITAC Telecommunications Subcommittee
> Subject: Re: [teitac-telecom] Comments re: the proposed revisions to
> 1194.23(k)
>
> K-1, K-1, and K-3 are appropriately hardware requirements. We did
> discuss coverage of them In Closed, but this was prior to the
> expansion of the desktop group to include all hardware.
> K-4 is interesting. It's a software function, but as Paul points out
> it's a software function very specific to telecomm and as such should
> probably be addressed and retained in this group.

From: Debbie Cook
Date: Tue, Mar 06 2007 9:45 AM
Subject: Re: Comments re: duplication of requirements indifferent sections

If we cannot get to a place where we understand that compliance is to the
standard as a whole, we will never be able to adequately expect compliance
with the Funciton part of the standards. This in fact has been a serious
concern I have all along. The functional criteria are not synonomous with
equivalent facilitation. In fact, many access areas are not addressed unless
you consider the functional standards. Very recently I observed a product
developer sorting through the applicable provisions for their product, and
they only considered the technical standareds. The product under discussion
actually had compliance chunks in various technical standards, and those
fell short of addressing the issue without the funcitonal ones. So, we have
to move away from the notion that certain standards are written for certain
products. I like the concept of the Buy Accessible Wizzard and am wondering
how far afield it is from Gregg's proposal?
----- Original Message -----
From: < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Telecommunications Subcommittee"
< = EMAIL ADDRESS REMOVED = >
Cc: "TEITAC Telecommunications Subcommittee"
< = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, March 06, 2007 8:24 AM
Subject: Re: [teitac-telecom] Comments re: duplication of requirements in
different sections


To address the point of a comprehensive list - there is one; it is the
Standard itself. The only utility provided by the categories that the
provisions are grouped under (software applications and operating systems,
web-based intranet and internet information and applications,
telecommunications products, video and multimedia, self contained, closed
products and desktop and portable computers) is ease of understanding by
providing a mental image of what the provisions that followed most likely
pertained to. The categories were problematic from day one because we
already had products that bridged categories (think smart phones and
all-in-one printers). The Standards addressed this by the very first
sentence in 1194.2 Application "(a) Products covered by this part shall
comply with all applicable provisions of this part." No mention at all of
the category as a delimitator.

The Access Board has been steadfast in its position that the existing
provisions not be distilled down into an easy to use/ understand list
because they felt that was the intention of the Standard itself. We can
decide to simplify this in the refresh activities, but getting agreement
on shorthand sentences are as difficult as coming to consensus on the full
text.

The problem with the approach that Paul and Tom suggest is that creating a
comprehensive list of provisions that apply to specific products is the
effort required to keep it updated. As a government buyer, I don't know
how we could do that even if we knew what was coming next as technology
advances. Since it has taken 7 years to update the first iteration of the
Standards, I wouldn't want to design a process that would require frequent
updates to make the Standard relevant to new innovations in technology.

Regarding the BAW: the intended use of the Buy Accessible Wizard is to
first and foremost ensure uniform compliance within the Federal
government's buying community. The provisions as written are not
understandable by the vast numbers of people who have to use them so the
Wizard has reverse engineered the provisions to the characteristics. To
make it understandable to the Fed buyer, the BAW asks a series of
questions that the buyer should know, such as will the product to be
purchased have a keyboard or will it connect to a system, etc. By design,
it incorporates as applicable as many provisions as possible so that it
doesn't inadvertently leave out something. And since this applicability
step is the lead in to the market research phase, that is appropriate. It
is clumsier for product engineers and designers but they aren't the
intended audience. It enables Fed buyers to refine their agency's
requirements by discovering what is available in the commercial market
place before the agency issues its RFP.






"Michaelis, Paul R. (Paul)" < = EMAIL ADDRESS REMOVED = >
Sent by: = EMAIL ADDRESS REMOVED =
03/06/2007 09:16 AM
Please respond to
"TEITAC Telecommunications Subcommittee" < = EMAIL ADDRESS REMOVED = >


To
"TEITAC Telecommunications Subcommittee" < = EMAIL ADDRESS REMOVED = >
cc

Subject
Re: [teitac-telecom] Comments re: duplication of requirements in different
sections






I agree completely with what Tom has said. I cannot ensure conformance
if I cannot point my telecom engineers and product managers to a single,
complete list of the requirements that apply to their products. It's
silly to burden them with an additional requirement that they use the
Buy Accessible Wizard to see what applies. (BTW, as a separate issues,
the Wizard does not always provide sensible recommendations...) If this
means that some of the requirements will continue to be duplicated in
different sections, this is a very small price to pay in exchange for
ease-of-use and greater likelihood of conformance.

-- Paul Michaelis



I don't understand why some people think it's a problem if requirements
are duplicated in different sections.

-----Original Message-----
From: Tom Brett [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, March 06, 2007 2:48 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] Comments re: the proposed revisionsto
1194.23(k)

I do not agree. Many developers or requiring officials will state that
if the provision is not listed for the category of product that I am
working on then the provision does not apply. This has occurred many
times in the past. While not duplicating the provisions would seem to
be the most efficient way to show the provisions for knowledgeable
individuals, these standards should be written for those who only have a
passing interest or need. When the supervisor directs the Grade 4 clerk
to purchase a EIT item, the clerk is going to take the path of least
resistance. Not all agencies use the GSA Buy Accessible Wizard that
would enumerate the standards & provisions and there needs to be a
comprehensive list of standards/provisions that someone can look at to
evaluate the conformance of the product.

Tom Brett


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Tuesday, March 06, 2007 12:41 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] Comments re: the proposed revisionsto
1194.23(k)

Everything in the hardware section would apply to telecom that is
hardware.
So you don't need to duplicate them.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Debbie
> Cook
> Sent: Monday, March 05, 2007 2:40 PM
> To: TEITAC Telecommunications Subcommittee
> Subject: Re: [teitac-telecom] Comments re: the proposed revisions to
> 1194.23(k)
>
> K-1, K-1, and K-3 are appropriately hardware requirements. We did
> discuss coverage of them In Closed, but this was prior to the
> expansion of the desktop group to include all hardware.
> K-4 is interesting. It's a software function, but as Paul points out
> it's a software function very specific to telecomm and as such should
> probably be addressed and retained in this group.




--------------------------------------------------------------------------------