Document Number: AUSTIN/67
Title: XRATd5 Aardvark Change Request Report (DRAFT)
Revision Date: 2000-3-1
Source: Andrew Josey, Chair
Action: for review
This report contains the editors proposed dispositions of the aardvark comments
submitted against the XRAT Draft 5.
XRAT
Aardvark Summary Table
______________________
ERN 1 Accept as marked
ERN 2
ERN 3
ERN 4 Accept
ERN 5 Duplicate of X
ERN 6 Accept
ERN 7
ERN 8 Accept
ERN 9
ERN 10
ERN 11 Accept
ERN 12 Duplicate of X
ERN 13
ERN 14 Accept as marked
ERN 15 Accept
_____________________________________________________________________________
COMMENT Enhancement Request Number 1
dwc@spartan.eng.sun.com BUG in XRATd5 (rdvk# 15)
[DWC-8] Wed, 14 Feb 2001 23:57:31 -0800 (PST)
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
See Ed recommendation
_____________________________________________________________________________
Page: 3300 Line: 76 Section: A.1.1
Problem:
(FIPS scope)
Since P1003.1a mandated FIPS 151-2 conformance, the requirement for FIPS
151-2 conformance is hidden in this revision unless the reader is familiar
with the scopes of the underlying base documents. The rationale should
clearly note that these requirements are now mandatory.
To keep the wording in the normative Scope in the XBD P1-4 L1-132 the same
as the IEEE PAR and the ISO/IEC work item, the text taken and slightly
modified from the Portability section of the XBD volume of SUSv2 given in
the action section below should be added to the Rationale volume.
Action:
Add new paragraphs after P3312 L76 in section A.1.1 Scope:
FIPS Requirements.
The Federal Information Processing Standards (FIPS) are a series of U.S.
government procurement standards managed and maintained on behalf of the
U.S. Department of Commerce by the National Institute of Standards and
Technology (NIST).
The following restrictions have been made in this version of IEEE Std
1003.1-200x in order to align with FIPS 151-2 requirements:
. The implementation will support {_POSIX_CHOWN_RESTRICTED}.
. The limit {NGROUPS_MAX} will be greater than or equal to 8.
. The implementation will support the setting of the group ID of a
file (when it is created) to that of the parent directory.
. The implementation will support {_POSIX_SAVED_IDS}.
. The implementation will support {_POSIX_VDISABLE}.
. The implementation will support {_POSIX_JOB_CONTROL}.
. The implementation will support {_POSIX_NO_TRUNC}.
. The read() call returns the number of bytes read when interrupted by
a signal and will not return -1.
. The write() call returns the number of bytes written when
interrupted by a signal and will not return -1.
. In the environment for the login shell, the environment variables
LOGNAME and HOME will be defined and have the properties described
in this document.
. The value of {CHILD_MAX} will be greater than or equal to 25.
. The value of {OPEN_MAX} will be greater than or equal to 20.
. The implementation will support the functionality associated with
the symbols CS7, CS8, CSTOPB, PARODD and PARENB defined in
.
[Ed recommendation: Accept as marked
need to change the use of "will" above to present tense as this
is rationale :
The following restrictions have been made in this version of IEEE Std
1003.1-200x in order to align with FIPS 151-2 requirements:
. The implementation supports {_POSIX_CHOWN_RESTRICTED}.
. The limit {NGROUPS_MAX} is now greater than or equal to 8.
. The implementation supports the setting of the group ID of a
file (when it is created) to that of the parent directory.
. The implementation supports {_POSIX_SAVED_IDS}.
. The implementation supports {_POSIX_VDISABLE}.
. The implementation supports {_POSIX_JOB_CONTROL}.
. The implementation supports {_POSIX_NO_TRUNC}.
. The read() call returns the number of bytes read when interrupted by
a signal and does not return -1.
. The write() call returns the number of bytes written when
interrupted by a signal and does not return -1.
. In the environment for the login shell, the environment variables
LOGNAME and HOME are defined and have the properties described
in this document.
. The value of {CHILD_MAX} is now greater than or equal to 25.
. The value of {OPEN_MAX} is now greater than or equal to 20.
. The implementation supports the functionality associated with
the symbols CS7, CS8, CSTOPB, PARODD and PARENB defined in
.
]
_____________________________________________________________________________
EDITORIAL Enhancement Request Number 2
Joseph S. Myers BUG in XRATd5 (rdvk# 8)
[JSM-16] Mon, 12 Feb 2001 19:49:43 +0000 (GMT)
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 3309 Line: 418 Section: Command
Problem:
The usage "different than" is sometimes objected to and grates
gratuitously for some readers of English.
Action:
Here and also at
page 3362 line 2647 section Terminal Access Control editorial
page 3492 line 8113 section gid_t editorial
page 3532 line 9716 section Function Definition Command editorial
Change "different than" to "different from".
page 3506 line 8680 section Utility Limits editorial
Change "different than are" to "different from those"
_____________________________________________________________________________
EDITORIAL Enhancement Request Number 3
donnte@microsoft.com Bug in xratd5 (rdvk# 1)
[DST-82] Wed, 10 Jan 2001 22:25:03 -0800
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 3313 Line: 570 Section: Job
Problem:
I think this should be 'was historically one' (consistent tense).
Action:
'is'->'was', but ask a grammer maven, as this is a grey area.
_____________________________________________________________________________
COMMENT Enhancement Request Number 4
gwinn@res.ray.com Bug in XRATd5 A.4.1.3 Seconds Since the Epoch (rdvk# 7)
{0102-5 } Mon, 12 Feb 2001 04:42:10 GMT
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 3334 Line: 1445 Section: A.4.1.3
Problem:
Leap seconds do not happen exactly once every 15 months, as this sentence
states. This rate is only a long-term average; the short-term rate
varies significantly.
Action:
Change to read "Historically, one leap second is added every 15 months on
average, so this offset ...", the phrase "on average" having been added.
[Ed recommendation: Accept]
_____________________________________________________________________________
COMMENT Enhancement Request Number 5
donnte@microsoft.com Bug in xratd5 (rdvk# 2)
[DST-83] Wed, 10 Jan 2001 22:25:03 -0800
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_of_X Reject_____
Rationale for rejected or partial changes:
See Ed recommendation
_____________________________________________________________________________
Page: 3334 Line: 1445 Section: A.4.13
Problem:
Don't imply more than you intend.
Action:
"added every" -> "added approximately every".
[Ed recommendation: DUP]
_____________________________________________________________________________
COMMENT Enhancement Request Number 6
gwinn@res.ray.com Bug in XRATd5 A.4.1.3 Seconds Since the Epoch (rdvk# 6)
{0102-6 } Mon, 12 Feb 2001 04:44:29 GMT
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 3334 Line: 1468 Section: A.4.1.3
Problem:
The last sentence of line 1468 seems out of place, and is
hard to interpret.
Action:
Delete sentence, which begins "These concerns ...".
[Ed recommendation: Accept]
_____________________________________________________________________________
COMMENT Enhancement Request Number 7
Jon.Hitchcock@uniplex.co.uk Bug in XRATd5 LC_TIME (rdvk# 14)
{jjh46} Wed, 14 Feb 2001 17:50:30 GMT
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 3346 Line: 1957 Section: LC_TIME
Problem:
The first Christian era "AD" starts in year 1, not year 0.
[I have a copy of part of an XPG draft dated 10-Jan-1992,
where the "Locale" chapter consistently claims that the
Christian era "BC" is the time before January 1, AD 0.
It seems that this error was noticed, but this example
was overlooked when the specification was corrected.]
[Since these are just example definitions for the Christian
Era, there is no need to change "AD" and "BC" for political
correctness.]
Action:
Change "0000/01/01" to "0001/01/01"
_____________________________________________________________________________
EDITORIAL Enhancement Request Number 8
Jon.Hitchcock@uniplex.co.uk Bug in XRATd5 LC_MESSAGES (rdvk# 13)
{jjh47} Wed, 14 Feb 2001 17:58:42 GMT
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 3346 Line: 1962-5 Section: LC_MESSAGES
Problem:
YESSTR and NOSTR are not marked LEGACY, they have been removed.
Action:
Change lines 1962-5, "However, ..." to "Applications should use
the general locale-based messaging facilities to issue prompting
messages which include sample desired responses."
[Ed recommendation: Accept]
_____________________________________________________________________________
OBJECTION Enhancement Request Number 9
keld@dkuug.dk bugs in d5 (rdvk# 9)
[KS-6] Wed, 14 Feb 2001 09:02:32 +0100
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 3352 Line: 2290-2296 Section: regexp
Problem:
The standard should support multi-character collation element
matching, as the ISO/IEC 9945-2:1993 standard does.
Action:
Delete the sentence on multicharacter collating elements in line 2290-2296
_____________________________________________________________________________
OBJECTION Enhancement Request Number 10
keld@dkuug.dk bugs in d5 (rdvk# 10)
[KS-7] Wed, 14 Feb 2001 09:02:32 +0100
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 3355 Line: 2366-2402 Section: regexp
Problem:
The standard should support multi-character collation element
matching, as the ISO/IEC 9945-2:1993 standard does.
The text present here is misguided.
The French example is not likely.
The POSIX standard does not prescribe use of specific implementation
techniques such as deterministic finite-state automatons.
The standard does not address user-space implementations.
Action:
Delete lines 2366-2402
_____________________________________________________________________________
EDITORIAL Enhancement Request Number 11
Jon Hitchcock Bug in XRATd5 POSIX.1 Symbols (rdvk# 11)
{jjh37} Wed, 14 Feb 2001 11:16:24 -0000
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 3376 Line: 3034-3037 Section: POSIX.1
Problem:
Lines 3034-3047 duplicate lines 3019-3022. The reference to
"these feature test macros" (plural) shows that the first occurrence
(where it refers to _POSIX_C_SOURCE and _XOPEN_SOURCE) is correct.
Action:
Remove lines 3034-3047.
[Ed recommendation: Accept]
_____________________________________________________________________________
COMMENT Enhancement Request Number 12
donnte@microsoft.com Bug in xratd5 (rdvk# 3)
[DST-84] Wed, 10 Jan 2001 22:25:03 -0800
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_of_X Reject_____
Rationale for rejected or partial changes:
See Ed recommendation
_____________________________________________________________________________
Page: 3376 Line: 3034 Section: Feature
Problem:
Duplicate of 3019. This repitition seems unnecessary, but if it
is deemed necessary, a separate subsection that applies to ALL feature
test macros would make more sense than the repitition.
Action:
Delete 3019-3022
[Ed recommendation: DUP]
_____________________________________________________________________________
COMMENT Enhancement Request Number 13
adjg@catullus.eng.sun.com Bugs in XRAT (rdvk# 12)
[] Wed, 14 Feb 2001 18:51:36 -0800 (PST)
_____________________________________________________________________________
Accept_____ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 3466 Line: 7070 Section: omitted
Problem:
People are continually confused about socklen_t.
Action:
Add the following rationale:
The type socklen_t is an unfortunate historical accident, and needed to
be invented to cover the range of implementations seen in the field.
The intent of socklen_t is to be the type for all lengths that are
naturally bounded in size, that is, that they are the length of a
buffer which cannot sensibly become of massive size: network addresses,
hostnames, string representations of these, ancillary data, control
messages, and socket options are examples. Truly boundless sizes are
represented by size_t as in read(), write(), etc.
All socklen_t types were originally (in BSD UNIX) of type int.
An overzealous unknown decided without significant review to "correct"
all buffer lengths to size_t, which appears on its face to make sense.
When dual mode 32/64 bit systems came along, this choice unnecessarily
complicated system interfaces because size_t (with long) was a different
size under ILP32 and LP64 models. Reverting to int would have happened
except that some systems had already shipped 64-bit only interfaces. The
compromise was a type which could be defined to be any size by the
implementation: socklen_t.
_____________________________________________________________________________
COMMENT Enhancement Request Number 14
donnte@microsoft.com Bug in xratd5 (rdvk# 4)
[DST-85] Wed, 10 Jan 2001 22:25:03 -0800
_____________________________________________________________________________
Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
See Ed recommendation
_____________________________________________________________________________
Page: 3544 Line: 10162 Section: cxref
Problem:
cxref is included as an XSI extension; that should be noted (or this
paragraph deleted).
Action:
TOG's call.
[Ed recommendation: Accept as marked
Delete line 10162-10164]
_____________________________________________________________________________
COMMENT Enhancement Request Number 15
donnte@microsoft.com Bug in xratd5 (rdvk# 5)
[DST-86] Wed, 10 Jan 2001 22:25:03 -0800
_____________________________________________________________________________
Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____
Rationale for rejected or partial changes:
_____________________________________________________________________________
Page: 3559 Line: 10645 Section: D.2.20
Problem:
"general networking" clearly is now in scope.
Action:
1) Delete "general networking".
2) Add new paragraph:
However, as the standards evolve, certain functionality once considered
"exotic" enough to be part of a separate standard become common enough
to be included in a core standard such as this. Real time and networking,
for example, have both moved from separate standards (with much
difficult cross-referencing) into this standard over time, and although
no specific areas have been identified for inclusion in future revisions,
such inclusions seem likely.
[Ed recommendation: Accept]