SC22/WG15 N555 SC22/WG15 USTAG N515 April 27, 1995 United States Action Item Report Attachment 1: WG15 US TAG N520 - Canada Questions Attachment 2: WG15 US TAG N521R - Modula 2 Response Attachment 3: WG15 USTAG N524 - Security Overlap ---------------------------------------------------------------------- WG15 A9410-01 United States: Investigate making electronic copies of draft documents available to WG15 (open action items 9305-33,9310-15, 9405-06) Response: CLOSED - We have investigated the issue and have found that IEEE Policies prohibit us from providing these documents in electronic form. The IEEE SEC Chair is sending a formal request to the IEEE Standards Board asking that the restristrictions on electronic drafts be altered to allow us to provide them to WG15. ---------------------------------------------------------------------- WG15 A9410-04 United States: Review the scope of WG15 POSIX security related items and position this work relative to the proposed program of work and terms of reference of SC21, SC18 and their working groups. United States member body will identify any areas of overlap and report their findings back to WG15 (open action item Paris-01, 9310-25, 9405-14) Response: Closed Document WG15USTAG N525 (Attachment 3) covers this issue. ---------------------------------------------------------------------- WG15 A9410-06 Member bodies: Comment on the WG15 RIN position on ISO 10646 (32 bit character set) impact on POSIX standards (open action item 9310-47, 9405-23) Response: OPEN - The RIN report has not yet been received as a WG15 document. Therefore it could not be reviewed. Suggest the action item be closed until the report is distributed. It is now over a year and a half since the action item was originally assigned. ---------------------------------------------------------------------- WG15 A9410-16 Member bodies: Notify Project Editor of the names of the Participants for the synchronization ad hoc by December 21, 1994. Response: CLOSED. Participants were: Barry Needham, Jay Ashford, Lorraine Kevra, Roger Martin, and Lowell Johnson. ---------------------------------------------------------------------- WG15 A9410-17 United States: Report to the next WG15 meeting (May 1995) as to the status as defined in SD-11 for LIS, TFA, PII (Protocol Independent Interfaces), and Directory Services, and deliver a draft resolution for WG15 consideration with respect to reporting to SC22 on WG15 plans for bringing documents forward. Response: CLOSED PASC has no active projects in the Directory Services area. While PASC has a project for LIS (P1372) the project is not currently active and we expect no documents to be brought in the near future. Protocol Independent Interface (PII) (P1003.1g) is an active project and is nearing IEEE final recirculation and we expect a document to be forwarded to WG15 shortly. TFA is an active project and is about to go to final IEEE recirculation and we anticipate the document to be distributed to SC22 for review and comment at that time. ---------------------------------------------------------------------- WG15 A9410-19 Member bodies: Provide input on the identification of existing conformance testing activities to the WG15 RGCT Rapporteur (See N526, section 5.1) Response: CLOSED ---------------------------------------------------------------------- WG15 A9410-20 United States: Provide information on the status of 1326, 1326.1, 1326.2, 1328, 1328.1, and 1328.2 test method standards with respect to ISO standardization activities. Response: CLOSED A technical editor has been identified for all of these standards. The technical editor is Chris Harding of X/Open (thanks). ---------------------------------------------------------------------- WG15 A9410-22 Member bodies: Submit names to be included in the synchronization Email list to Keld Simonsen by Nov. 1994. Response: CLOSED ---------------------------------------------------------------------- WG15 A9410-24 United States: Distribute to the WG15 Email list the details on its proposal on CHARIDS, (see action item 9405-55) and US Response (SC22/WG15 N515) Response: CLOSED The resulting changes to P1003.2b will appear in Draft 11 of that docuument. Draft 11 was being prepared at the 4/95 PASC Meeting and is already approved for distribution as CD/PDAM Registration and Ballot. This was mailed to cpwg-mail@revcan.ca and SC22WG15 mailing list on 4/27/95. ---------------------------------------------------------------------- WG15 A9410-26 Forward the following documents to the convener for SC22/WG15 Review and Comment: P1003.2b Shell and Utilities - Extensions Draft 10 P1003.1i Technical Corrections to Real Time API Extensions - Draft 2 P2003R Test Methods for Measuring Conformance to POSIX Standards (revision of IEEE Std. 1003.3:1991) Draft 5 Response: OPEN P1003.2b Draft 10 was circulated as WG15 N531. P1003.1i was approved for forwarding at the 4/95 WG15TAG meeting and should be arriving shortly. P2003R has been approved for forwarding at the 10/94 WG15TAG meeting and should be forwarded shortly. ---------------------------------------------------------------------- WG15 A9410-27 Member bodies: Review the documents listed in 9410-27 (ed. note I think this means 9410-26) Response: OPEN - The US has reviewed the documents which have been forwarded. ---------------------------------------------------------------------- WG15 A9410-29 Refer WG15 N409 (Modula II binding queries) to PASC and report back at the May 1995 WG15 meeting. Response: CLOSED - The responses are contained in attachment 2 of this report. This is WG15 USTAG N521 dated April 27, 1995. ---------------------------------------------------------------------- WG15 A9410-30 Member bodies: Review SC22/WG15 N511 (A Discussion Paper on POSIX Applications Conformance dated 1994-10-01) and provide feedback to the SC22/WG15 Email distribution list. Response: CLOSED - The response is in WG15USTAG N503. This was sent to the SC22WG15 Mailing list as SC22WG15.491 and discussed in messages SC22WG15.493 SC22WG15.494 and SC22WG15.496. ---------------------------------------------------------------------- WG15 A9410-32 Member bodies: Provide attendee list for the October 1995 meeting to Barry Needham by the May 1995 WG15 meeting. Response: CLOSED - At the 1/95 WG15USTAG meeting, the delegation was appointed and consisted of 9 members. ---------------------------------------------------------------------- WG15 A9410-35 Member bodies: Look at the technical aspects of SC22/WG15 N444 (CEN Cultural Elements Registry) and the applicable portion of SC22/WG15 N515, (This document is the October US Action Item Report see A9405-42) in time for the May 1995 SC22/WG15 meeting. Response: CLOSED - We have reviewed the document and have no further comment. ---------------------------------------------------------------------- WG15 A9410-37 Member bodies: Indicate a preference as to which part of Canada should be considered for the Fall 1997 meeting by the May 1995 meeting. Response: CLOSED - We have considered this issue and have no strong preference in this area. Possiblecities suggested by the WG15 US TAG members included: Montreal (if it is still in Canada :) ), Edmonton, and Calgary. ---------------------------------------------------------------------- WG15 A9410-38 Recommend a course of action with respect to directory services area of work by the May 1995 SC22/WG15 meeting. Response: CLOSED (see WG15 A9410-17) PASC has no active projects in the Directory Services area and recommends this work item be dropped. Attachment 1 SC22/WG15 US TAG N520 IEEE P1003.2 N269 April 26, 1995 Page 1 of 2 Topic: Response to SC22/WG15 Action Item A9410-24 From: Donald W. Cragun I apologize for the delay in this response. The first draft containing full text of the changes for this proposal was not printed until last week. The questions submitted by Canada with our responses are below: 1) a) Could the US present the precise format of the proposed new charmap file? Draft 10.9 will be available from the US delegation at the Enschede meeting. Draft 11 will be distributed for concurrent registration and ballot soon. b) Specifically, could the US explain the relationship of the new proposed field to the portion of each line that is now considered "comment" or explanatory material? The proposal does not include a new field. If just allows two additional forms for specifying the part of the the existing forms. The portion of the lines between CHARMAP and END CHARMAP are not changed. c) Has the been used to delimit RHS comments (i.e. those comments that do not start at the beginning of the line)? Empty lines and lines starting with the are comments. The field can contain any characters (within the context of a line in a text file). Comments are separated from the by one or more characters. A could be used after the required as a convention to make the charmap files easier to read by humans, but are not required by the current standard or the proposed changes. 2) a) Could the US explain the need for the addition of a new parameter to the localedef utility? The new option (-u code_set_name), specifies the name of a code set to be used as the target mapping of character symbols and collating element symbols whose encodings are defined in terms of ISO 10646 position constant values. SC22/WG15 US TAG N520 IEEE P1003.2 N269 April 26, 1995 Page 2 of 2 b) Would not a similar effect be achieved by manipulating the charmap with the standard text utilities and then using the existing localedef utility? None of the other standard utilities specified in 9945-2 (even the iconv utility in P1003.2b) is designed to translate from ISO 10646 16- or 32-bit values encoded as strings of the form or to octal, decimal, or hexadecimal encodings of the forms expected in charmap files by localedef. Scripts could be created using awk or sed to perform these translations manually, but the P1003.2 working group believes that implementations should be able to translate from 10646 to codesets supported by the implementation without manual assistance. 3) a) Could the US explain what is meant by "... have localedef predefine mappings for the standard symbolic names for characters in the character set defined by 9945-2 Section 2.4"? Canada is aware that 9945-2 specifies standard symbolic names for the characters referenced in Section 2.4. Canada's question relates to the "... localedef predefine mappings ...". Since the 10646 encodings for all of the characters in Table 2-4 in section 2.4 of 9945-2 are always the same, they need not be specified in charmap files that are encoded using the new formats; localedef will be required to supply the encoding information using the values specified in Table 2-4 implicitly. Attachment 2 WG15 TAG N521R April 27, 1995 PASC SICC RESPONSE TO US TAG N509 MODULA-2 QUESTIONS As requested by PASC SEC Action WG15 A9410-29, PASC SICC has examined the questions contained in US TAG document N509 and developed responses to them. The SICC has several general comments regarding the Modula-2 binding in general. PASC SICC notes that this list of "questions" is more accurately described as a combined list of observations about 1003.1x C binding standards and binding design decisions made by the Modula-2 binding working group, and that the submittors of the questions are mostly looking for confirmation of their observations and choices. PASC SICC suggests that a review of the Ada binding IEEE 1003.5 should be considered as a basis of the Modula-2 binding. The two languages have a great deal in common and many of the same principles that were used in the Ada can be applied to Modula-2. The binding to the real-time interface (1003.1b) is currently in ballot as IEEE P1003.5b (draft 5). Finally, PASC SICC would like to remind JTC1 SC22 WG15 that there is no on-going work within the IEEE to develop Language Independent Specifications for the 1003.1 family of standards. Specific Queries 1) Separation of process_id and process_group_id as types In the Ada binding there were two independent private types used for Process_Group_ID and Process_ID. The Ada package POSIX_Process_Identification contains the Get_Process_ID, Get_Parent_Process_ID and Get_Process_Group_ID procedures, as well as the Set_Process_Group_ID, Create_Process_Group and Create_Session procedures. There are also functions called Value and Image that convert the Ids to string and back. The Ada binding did use function overloading to implement Value and Image. 2) Missing get_argument_list operation Draft 12 of IEEE 1003.1a contains a function getopt() in section 4.9, immediately following getenv(). This would appear to map into get_argument_list, although this has not been specified in a language-independent fashion. The action taken in the Modula-2 binding appears to be appropriate in this context, although the operation defined in the binding appears not to map to getopt(); instead, that operation simply fetches argv. The modula-2 binding should take careful note of section 4.3.2.2, lines 311-315, in draft 3 of the LIS. 3) Signal names All signals should be named constants. In the Ada real time binding, a range type is uses to define the range of the real-time signals. This is purely a matter for language bindings to decide; however, the LIS does use names like SIGABRT (although SIGBUS appears to be missing). There is no such table in 1003.16 (C binding) as suggested in the question. 4) Redundancy of set operations in Section 5.2.3 Other languages need these operations including Ada, but Modula-2 does not. It is acceptable for a language binding to omit some services if they are already provided by the language. 5) Missing normative reference to Coordinated Universal Time Good point. The Operating System Services WG will add the appropriate normative reference to the next drafts of 1003.1a and .1LIS. 6) Section numbering suggestions The numbering scheme used in the LI specifications is used nowhere else in the IEEE standards. The following section numbering scheme is in use: 6.7 Async I/O 11 Semaphores 12 Memory management 15 Messaging 13 Scheduling 14 Timers Because the order in which the various supplements to 1003.1 will be completed cannot be determined with certainty over any period of time longer than about six months, it is not possible to provide section numbers for sections contained in standards which have not completed ballot. The IEEE editorial plan is to assign section numbers in order of addition to the base standard; that is, "holes" in section numbering cannot be created to leave room for supplements which will complete at a later date. 7) Shortening of names: terminal_device The names is the LIS were not recommended names. The names were chosen just so that they would not be the same as any in use. The Ada group recommended that the names they had used be used by the LIS. This is a matter which can be decided by the individual binding group. 8) Shortening of names: "attributes" This is a matter which can be decided by the individual binding group. 9) Shortening of names: "descriptor" This is a matter which can be decided by the individual binding group. It is important, though, that the binding remain internally consistent with itself in this respect. 10) Error condition for get-terminal-name (8.3.7) In the Ada binding either an empty string is returned or an error condition is raised. We assumed that the Ada binding is implemented on the C interface. 11) Negative 'values' for semaphores Again, this appears to be a matter which can be decided by the individual binding. The LI version would merely require that the interface be capable of returning a value from one of the two domains, leaving up to the binding the decision as to how to perform this. The approach used in the Modula-2 binding seems quite reasonable. 12) Message queue attributes record and statically constant fields Of the four fields of the message queue attributes, one can be set and queried at any time, two can be set at creation time and queried at any time, and another one can only be queried. The WG estimates that the different kinds of access permitted do not justify separating these attributes into different objects and providing the necessary operations on all those objects, since they all represent attributes of the message queue. 13) Message passing contents The intent is arbitrary data structures, much like read() and write() are stated in terms of characters but in fact can be used to operate on arbitrary structures. 14) Thread scheduling - get/set style 15) (related question) There are differences in the way process and thread scheduling parameters and policies are handled, but they do not represent any problem from a functional point of view. The thread interface is different because the parameters are handled in a different way (through thread creation attributes), and also because the method for error handling in the threads interface differs from the old non-thread-safe method used elsewhere in the 1003.1x standards. The Modula-2 binding should use whatever style is most appropriate to the language and which is consistent within the binding. SICC would caution the Modula-2 binding WG to consider thread-safety issues when designing error return mechanisms. 16) Thread cancellation state/kind There is no interface to retrieve the cancellation state of a thread because this was considered unnecessary. There are two usual operations regarding cancellation state: disabling cancellation state, and restoring it to the original value. Both operations can be achieved with the current interface. In general, reading the cancellation state or directly enabling are neither required nor recommended. For additional information, please see the rationale for the pthread_setcancelstate() function in section 18.2.2.5 of 1003.1c Draft 10. 17) Should the term _POSIX_PRV in P1003.1e.23.4.9.2 be _POSIX_CAP? This also occurs in 23.9.4, 23.10.xx and several other places. Response: This has been corected in later drafts - your assumption is correct. 18) Why is there no size parameter to the external-to-internal conversion operation defined in 23.4.7? It is possible that an accidental sequencing of bit-patterns in the storage area beginning at the address given may extend well beyond the area defined by the application when calling the operation. It would be most unfortunate if this were not to be treated as an error! Response: It is stated in the standard that the implementation can return an error if the format of the representation is not recognized. This would include the case you site. The external representation of the external format is well defined. It was decided by the ballot group that the overhead of a length parameter was not desired, and the probablility of what you site occurring is too low to mandate the overhead for all bindings. 19) It is suggested that the second use of acl_get_entry on line 756 of 23.4.8.2 of P1003.1e be acl_create_entry? Response: This has been corrected in Draft 15. 20) The C binding definition of the services to get and set the user and group identifies for an ACL entry (23.4.21 and .27) uses a single type for the result. The LI version does not permit this as it has different types defined. However, it is suggested that this therefore means there is need for a pre-condition on the service definitions that the entry is of an appropriate type, or there must be another reason for failure relating to an inappropriate entry class. Response: Still under investigation 21)In P1003.1e section 23.4 there are four set manipulation operations. For the reasons given in item 4 above, it is suggested that these are not relevant to the LI version. Response: **TBD** 22)In P1003.1e section 25 there are many cross references to services in the wrong subsections (just see 25.4.10.5 for an example). Response: This has been corrceted in Draft 15. 23)The name Not_audit_event has been substituted for "No_field_id" as given in Table 9 on p115 of P1003.1e for naming consistency. Is this acceptable? Response: **TBD** 24)In P1003.1e 24.2.2.12 there are two incorrect field identifiers. The characters '_ID' at the end should be deleted. Response: **TBD** 25)There is an inconsistency between sections 24 and 25 of P1003.1e. Section 25 defines a type cap_t but in 24.3.4 Table 11 this appears as two types cap_file_t and cap_proc_t! Only one is needed! Response: There is only cap_t. The table is incorrect and has been corrected in D15. 26)The entries in Table 11 in 24.3.4 of P1003.1e are certainly not consistent with a type-safe model as in the LI draft of earlier parts of the standard. The entries for char. int. long. opaque and short are never referred to elsewhere. The int variant covers four different types - file-descriptor (a subrange), file-mode (a set), file-open-flags (an enumeration) and exit reasons (s subrange). [Incidentally, the last type is anonymous in Section 4.3.3.1 of the LI draft. Since it necessarily appears in this audit contact then it is suggested that it should be named (eg final_reasons as suggested in the Modula-2 binding in POSIX Processes).] The 'string array' variant is, of course, some kind of array of records for environ list and an array of strings only for the argument list - as defined in section 2.3 of the LI draft. This variant offers the only serious problem in the whole binding to Modula-2 as the language does not support dynamically sized types directly - but only through a rather arbitrary and not very safe 'fiddle' involving defining a pointer to an arbitrarily large object and then using it safely (if the programmer is lucky). At the moment, for the first working draft binding this is left as a 'todo' in collaboration with further LI drafting. Response: **TBD** 27)Consequent on there being only one 'capability type' there only needs to be one capability field name in P1003.1e 24.2.2.nn sub-sections (un = 27, 28, 29)! Response: **TBD** 28)Table 14 in Section 24.3.9 of P1003.1e refers to 'privilege' and 'PRIV'. Both here and in the notes below it these should, we suggest, refer to capabilities. Response: Your assumptionis correct. "privilege" should be "capability" and "PRIV" should be "CAP". 29)24.3.11 of P1003.1e defines a type aud_time_t. This is, identical to the type defined in Section 14 of P1003.1a - in the Modula-2 binding as POSIXTimers.Time_specifier! It is suggested, therefore, that this should be the type used in Section 24. Response: The POSIX Security Extensions group will study this suggestion and report later. 30)The services defined as get_xxx_info in Section 24.4 of P1003.1e seem to be three 'retrieval' services in one: - a. Obtaining the first data item in a list. b. Obtaining the next data item in a list. c. Obtaining a data item from a list by indexing. plus a list count service. As specified in the C language binding, all three variants return the number of entries in the list. While this is possibly reasonable for the third (although is need is not understood), the first and second variants have no way of indicating which field data is being obtained. Since there is not a one-to-one correspondence between field type and field identity, this seems somewhat strange, since the application program will most probably need to be able to determine this for further processing From a consistency point of view, it is therefore suggested that there is need for the four services to be slightly different from their current definition - as follows: - a. Obtain the first item in the list - and the field identity. b. Obtain the next item in the list 0 and the field identity. c. Obtain a specified item (by field identify) from the list. d. Obtain a count of the number of items in the list. Whether the third of these returns anything or not is a matter of taste, although there seems to be some merit in returning the sequence number in the list so that an application handling retrieval by a combination of identified fields in the 'next' fields can avoid duplication of handling of explicitly obtained data. Response: The POSIX Security Extensions group will study this suggestion and report later. 31)Table 18 in Section 24.4.24.2 of P1003.1e has an entry on line 1994 and a following note which is not understood. If the data type is a single group identity then it seems strange for the note to exist as its relevance is mystifying. However, if the data type is intended to be a list/array of group identities then the note is probably sensible, but the data type is a new one! For the purposes of the working draft binding to Modula-2 this assumption has been made. Response: **TBD** 32)It is unclear from the definition of audit reading and writing in P1003.1e section 24 whether the default file descriptor identifying the system audit trail is a proper file descriptor in the sense that its domain is the type defined in section 2.3 of the LI draft. If this is true, then this would seem to imply that an application now has four 'standard files' - input, output, error and system-audit trail. This implication seems rather strange. It therefore seems possible that the intention is that there are additional special services for reading from and writing to the system audit trail - which will need defining in the LI working draft. As a temporary measure in the Modula-2 binding which will need defining in the LI working draft. As a temporary measure in Modula-2 binding draft has presumed that the system audit trail identifier is a normal 'pre-opened' file descriptor. Response: **TBD** 33) PAGESIZE vs. POSIX_PAGESIZE 34) File mode options are defined twice It would appear that the .16 thin C binding does not contain a mapping between the file_creation_mask_type from LIS to anything useful (although there is a mapping to file_permissions_type to stat.h values). In the face of this, we cannot see any purpose in the file_creation_mask_type, and agree with the conclusions of the modula-2 binding. 35) Access_kinds_type is a subrange We are not actively working on LI versions of 1003.1b or 1003.1e but we thank WG13 for the suggestion. 36) Audit interface and open flags as subrange We are not actively working on LI versions of 1003.1e at present, but the input from WG13 appears useful and we thank them for it. 37) Open flags for message queues 38) Message-queue-attributes-type component While each of these values (open flags and message queue attributes) have only one flag defined for each at this time, it is believed these should not be specified as boolean values because additional flags may be required in the future. Greater forward-compatibility of the binding is best preserved by representing these in "flag" types rather than as booleans. 39) Logical set operations for standard threads See question 4. We note that the Ada binding for threads (P1003.5b D3) are very simple (they only include synchroniszation and thread scheduling) because Ada already has a mechanism for expressing concurrent threads of control. Note, however, that the language services must work in a multithreaded application. 40) Anonymous types in the standard threads LIS There is no work in progress on this LI specification. Attachment 3 WG15 US TAG N524 To: WG15 US TAG From: POSIX Security Working Group/Jon Spencer Re: SC22/WG15 Action Item A9410-04 Date: 1995 April 27 ========================================================================= Action Item Text: Review the scope of WG15 POSIX security related items and position this work relative to the proposed program of work and terms of reference of SC21, SC18 and their working groups. United States member body will identify any areas of overlap and report their findings back to WG15 (open action item Paris-01, 9310-25, 9405-14). Response: The following table lists the possible overlaps between the POSIX Security Working Group (and the study group on cryptographic methods) and the various working groups of SC18, SC21 and SC27. (SC27 has been included to meet the spirit of the action item.) Note that there are xx possible overlap statuses that can be reported: o No overlap: No conflicts or area of cooperation. o Attributes: The other working group may wish to reference the security attributes defined by 9945-1 in their work. o Overlap: The other working group is developing standards in the same areas as POSIX, or that may require the types of attributes and mechanisms being developed by POSIX. A recommendation for possible action by WG15 is included at the end of this report. OVERLAPS BETWEEN IEEE POSIX AND SC18, SC21 or SC27 ================================================== SC18 SC18/WG03 - Open Document Architecture (ODA) and ODA Content Notation Attributes It is possible the document objects (e.g., paragraphs) may wish to have associated security attributes. SC18/WG04 - Distributed Systems Communications Overlap The terms of reference for this group: "To develop standards for services, procedures and protocols that enable communication between applications on distributed systems." Clearly, security attributes, authentication and encryption techniques may be associated with this subject area. SC18/WG08 - Document Description and Processing Languages Attributes The terms of reference of this working group are sufficiently broad to suspect that security attributes may be associated with the objects they deal with (e.g., hypermedia documents). SC18/WG09 - User-Systems Intefaces and Symbols No overlap SC21 SC21/WG01 - OSI Architecture Overlap This working group is responsible for the OSI Reference Model. As such, security issues may be addressed. The possible overlap is most likely with P1003.22. SC21/WG03 - Database Attributes Database objects clearly may have security attributes. If interfaces are referenced for dealing with these attributes, then there may be an overlap as well. SC21/WG04 - OSI Management and OSI Directory No overlap SC21/WG07 - Basic Reference Model of Open Distributed Processing Overlap The basic models they are developing should include security considerations, and the possible overlap is most likely with P1003.22. SC21/WG08 - OSI Upper Layers Attributes SC21/WG09 - Conformity Assessment Documentation No overlap SC27 SC27/WG01 - Overlap This group deals with "the provision of security services." Thus, there is expected overlap with POSIX. SC27/WG02 - Security Techniques and Mechanisms Overlap "WG 2 provides a center of expertise for the standardization of IT Security techniques and mechanisms within JTC1." Clearly, this overlaps strongly with POSIX, and some type of liaison is recommended. SC27/WG03 - Security Evaluation Criteria No overlap Within SC27, we see overlaps with the following projects. 1.27.01 1.27.08.01 1.27.02 1.27.08.02 1.27.03.01 1.27.08.03 1.27.03.02 1.27.19.01 1.27.03.03 1.27.10 1.27.03.04 1.27.14.01 1.27.03.05 1.27.14.02 1.27.04 1.27.14.03 1.27.06.01 1.27.18.01 1.27.06.02 1.27.18.02 1.27.06.03 1.27.18.03 1.27.07 1.27.18.04 RECOMMENDATIONS =============== WG15 may wish to consider the initiating the following actions. 1. Send the appropriate POSIX draft documents to groups within SC18, SC21 and SC27 where there is some overlap, and request input as to whether further liaison activities would be benficial. The documents should be accompanied by a cover letter explaining the possible areas of shared interest. 2. Follow up on these communications to ensure that (1) we have received appropriate responses and (2) liaison activities are established as appropriate.