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]