INCITS, 1101 K St NW, Washington, DC 20005, USA
17-18 September 2015: 0900-1700 EDT (1300-2100 UTC)
Please see document N0567 Local Arrangements for SC 22/WG 23 Meeting 38.
IMPORTANT:
Teleconference Info
SC
22/WG 23 Meeting 38 to Friday, September 18, 2015 9:00 am | Eastern Daylight Time (New York, GMT-04:00) 8 hrs Meeting number: 954 560 185 Meeting password: wg23 Join by phone 0800-051-3810 Call-in toll-free number (UK) +44-203-478-5289 Call-in toll number (UK) Access code: 954 560 185 Toll-free calling restrictions Add this meeting to your calendar. Can't join the meeting? Contact support. |
|
|
||||
2016 |
||||
#47 #46 #45 #44 #43 #42 |
November 2016 October 2016 TBD Sep 2016 TBD June 2016 TBD May 2016 April 14-15 |
Teleconference Teleconference With SC 22 Plenary Face-to Face, location TBD Teleconference (UTC 2000, 2 hr) BSI, London UK, with SC 22/WG 14 |
|
|
#43 #42 #41 |
7 March 2016 8 Feb 2016 11 Jan 2016 |
Teleconference (UTC 2100, 2 hr) Teleconference (UTC 2100, 2 hr) Teleconference (UTC 2100, 2 hr) |
||
|
||||
2015 |
||||
#40 |
23/11/15 |
Teleconference (UTC 2100, 2 hr) |
oo |
|
#39 |
|
Cancelled as a P2P meeting. Teleconference? |
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
Subcommittee completed its 2015 Plenary on Tuesday 15 September 2015. WG 23 requested a formal project split of 22.24772 into 9 parts: Part 1 Language Independent; Part 2 Ada; Part 3 C; Part 4 Python; Part 5 Ruby; Part 6 Spark; Part 7 PHP; Part 8 Fortran; and Part 9 COBOL. The resolution for this item (15-07) passed unanimously.
WG 23 further requested that TR 24772-1, -2, -4 and -8 be commenced immediately, with a 36 month target date for publication, and a scope and editor assigned. The resolution for this item (15-08) passed unanimously.
Review document N0565
Document is in hands of WG 9 for updates.
Review document N0558 Python language vulnerabilities contributed by Santiago.
Review document N0560 Fortran language specific vulnerabilities
Review document N0580 which is an edit (from Stephen Michell) of N0554 for C language specific vulnerabilities contributed by Clive Pygott. Can we add any vulnerabilities for concurrency?
As available
Review newly created SD 6 for correctness and formatting.
At an earlier meeting, it was recommended that we consider developing programming standards to avoid section 7 (design) vulnerabilities. A discussion is needed as to what format such document(s) would take, what level of assurance they should target, i.e. scope, goals. Before going too far, should we draft an outline of a sample standard (or technical specification)?
An idea was presented this week to mine the guidance to user sections for common guidance, and to create a top N (N=10, N=25, etc) guidances that can be used by people creating programming guides. A reasonable place to put such guidance would be in section 5.
We have an issue with moving to ISO eCommittee, in that people that contribute that are not registered as NB experts get unequal access to documents. Other committees do not use the N-numbering system the way that we have. They use the N-numbers for official (process) documents such as minutes and agendas, and for product versions ready for ballot. All other documents are “informal”. Would such a process work for us? We could set up a CVS or a GIT system where it is easy and reliable to identify versions of a document as it is edited.