From ajosey at rdg.opengroup.org Wed Oct 1 00:40:52 2003 From: ajosey at rdg.opengroup.org (Andrew Josey) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] Re: gLSB-commands: SUSv3 [patch] (Jim Kingdon) In-Reply-To: lsb-confcall-request@lists.sourceforge.net's message as of Sep 30, 8:09pm. References: Message-ID: <1031001074052.ZM5762@skye.rdg.opengroup.org> You need to remember that the document being referred to is simultaneously an IEEE standard, and The Open Group Technical Standard [+ an ISO/IEC Std], and has two sets of conformance requirements (POSIX Conformance and XSI Conformance). XSI Conformance and thus the XSI extension is a required part of the Single UNIX Specification Version 3. Its only optional if you are looking at the documents and aiming for POSIX Conformance. So when you compare the html versions of the Single UNIX Specification Versions 2 and 3, you need to include the XSI marked extensions. You also need to understand that certain POSIX options are mandatory for UNIX conformance, THR (Threads) is one that springs to mind. The conformance section has the full details. regards Andrew On Sep 30, 8:09pm in "Lsb-confcall digest,", lsb-confcall-request@lists.sourceforge.net wrote: > > > > 1) We want to cite SUSv3 with XSI. > > Ok, this means an extensive list of differences. > > The assumption was that SUSv3+XSI is closer to SUSv2 than SUSv3-XSI. > If that assumption is not true, maybe we want to cite SUSv3 without > XSI. The latter would mean that we have to figure out how not to > accidentally delete functionality that was in SUSv2 (and thus in LSB > 1.3). > > From gk4 at austin.ibm.com Mon Oct 6 06:38:50 2003 From: gk4 at austin.ibm.com (George Kraft) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] LSB Election Committee Message-ID: <1065447527.2235.289.camel@gkraft4> I would like to propose that we meet for about thirty minutes to discuss setting up an LSB election committee. I would like to suggest 30 minutes before this week's spec-auth meeting. -- George (gk4) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.linux-foundation.org/pipermail/lsb-sc/attachments/20031006/6663fe11/attachment.pgp From gk4 at austin.ibm.com Mon Oct 6 06:42:22 2003 From: gk4 at austin.ibm.com (George Kraft) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] LSB Election Committee setup Message-ID: <1065447742.2235.291.camel@gkraft4> A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1115 bytes Desc: not available Url : http://lists.linux-foundation.org/pipermail/lsb-sc/attachments/20031006/5382b9b4/attachment.icz From taggart at carmen.fc.hp.com Tue Oct 7 11:41:41 2003 From: taggart at carmen.fc.hp.com (Matt Taggart) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] Meeting Wednesday to discuss schedule Message-ID: <20031007184142.2794037D1C@carmen.fc.hp.com> Hi lsb-sc, It was decided at the lsb-futures meeting to have a Steering Committee meeting tommorrow, Steering Committee Schedule meeting Wednesday 10:30 west / 11:30 mountain / 12:30 central / 1:30 eastern We will be reviewing the Candidates at, http://www.linuxbase.org/futures/candidates/index.html Dial in number: 1-888-583-9625 access number 27844 -- Matt Taggart Linux and Open Source Lab taggart@fc.hp.com Hewlett-Packard From taggart at carmen.fc.hp.com Tue Oct 7 14:19:35 2003 From: taggart at carmen.fc.hp.com (Matt Taggart) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] lsb-sc mailing list Message-ID: <20031007211936.44C4237D1C@carmen.fc.hp.com> Hi, It turns out I wasn't on the lsb-sc list so Stuart added me. I was looking at the mailing list at, http://mail.freestandards.org/cgi-bin/mailman/listinfo/lsb-sc and the subscriber list is visible to anyone which is bad since spammers can harvest addresses. OK if we turn it off? The other issue is that the list archive is available to anyone as well. What's the purpose for the lsb-sc list? I was assuming it was for messages that couldn't go to the lsb-wg or lsb-discuss lists due to their sensative nature. Personally, I want to keep the project as open as possible but I'd be ok with a closed lsb-sc list as long as it's use is minimized to things that _have_ to be private. What do you think? Thanks, -- Matt Taggart Linux and Open Source Lab taggart@fc.hp.com Hewlett-Packard From taggart at carmen.fc.hp.com Tue Oct 7 21:16:11 2003 From: taggart at carmen.fc.hp.com (Matt Taggart) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] Change in meeting time Wednesday Message-ID: <20031008041612.E711137D1C@carmen.fc.hp.com> Hi lsb-sc, Ok change in meeting time so Chris can attend Steering Committee Schedule meeting Wednesday 8am west / 9 mountain / 10 central / 11 eastern / 1am AEST Dial in number: 1-888-583-9625 access number 27844 -- Matt Taggart Linux and Open Source Lab taggart@fc.hp.com Hewlett-Packard From cyeoh at samba.org Wed Oct 8 06:32:17 2003 From: cyeoh at samba.org (Christopher Yeoh) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] Meeting Wednesday to discuss schedule In-Reply-To: <20031007184142.2794037D1C@carmen.fc.hp.com> References: <20031007184142.2794037D1C@carmen.fc.hp.com> Message-ID: <16260.4577.767835.599415@gargle.gargle.HOWL> At 2003/10/7 12:41-0600 Matt Taggart writes: > Hi lsb-sc, > > It was decided at the lsb-futures meeting to have a Steering Committee > meeting tommorrow, > > Steering Committee Schedule meeting > Wednesday > 10:30 west / 11:30 mountain / 12:30 central / 1:30 eastern > > We will be reviewing the Candidates at, > http://www.linuxbase.org/futures/candidates/index.html > > Dial in number: 1-888-583-9625 access number 27844 This is partially an agenda, partially my understanding of the current state (given I didn't attend the lsb-futures meeting), and some random thoughts thrown in 1. 2.0 cut-of-date problems - things we really want in but are not yet ready - FHS 2.3 - might not be released in time - C++ - *really* has to be in 2.0 - maybe ok to add - I'm not exactly sure what is blocking it, but lack of test suites is not necessarily a reason not to add. We've done it before, and we have time before the cert program is to start - IPv6 - like C++, though not as urgent - TLS - Can we live without it? - Needed for NPTL which we really want, but requiring it requires TLS in implementation. - Who other than RH are willing to deploy it. - Needs 2.6 (not released), or 2.4 backport. - AIO - No choice really as no good implementation yet, nor will there be for 2.6. More of a 2.8 thing from what I've heard. Also heard kernel developers believe no real demand for all of aio. Maybe we need to help organise? - SUSv3 - No tests, but much like C++ should not necessarily stop us from including in spec - Man page work *must* be done - NPTL - See TLS 2. Various options i. Keep cut-of-date - accept less functionality in 2.0 - what is acceptable? - next release not for another year (better to delay by a couple of months to get more in?) ii. Move cut-off-date + keep LWE deadline (cert program) - how much more time do we need? - need time to get tests up and running iii. Move cut-off-date, move cert program iv. Move cut-off date, cert program doesn't include all tests we want. But plan on adding more test suites mid year. - We won't have good coverage for 2.0, but hey we don't have good coverage for 1.3 :-) - Worth the risk ? Chris -- cyeoh@au.ibm.com IBM OzLabs Linux Development Group Canberra, Australia From mats.d.wichmann at intel.com Wed Oct 8 06:47:25 2003 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] SC Meeting today Message-ID: I'm a little confused. We had a steering committee meeting for 30 minutes before specauth, now it's become 60 minutes before specauth with additional agenda. It looks from the agendas for the respective calls for meeting that this is on two different numbers, which isn't really useful, esp. if there turns out to be anyone who can only attend the second half hour. Since Matt posted his number for the on-the-hour call, can we stay with that one? From mats.d.wichmann at intel.com Wed Oct 8 07:16:39 2003 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] Meeting Wednesday to discuss schedule Message-ID: Pretty good summary, Chris. > This is partially an agenda, partially my understanding of the > current state (given I didn't attend the lsb-futures meeting), > and some random thoughts thrown in > > 1. 2.0 cut-of-date problems > - things we really want in but are not yet ready > - FHS 2.3 > - might not be released in time and still some concern about it as mandatory; e.g. RH is not too thrilled about /media - so it's not just Debian folks grumbling again. > - C++ > - *really* has to be in 2.0 > - maybe ok to add - I'm not exactly sure what is blocking > it, but lack of test suites is not necessarily a reason not > to add. We've done it before, and we have time before > the cert program is to start This is pretty much reasonable, except for a worry that we've been making too many exceptions, and recently, each one seems to burn us, so we probably shouldn't be making exceptions of this magnitude. The current state of testing is we have libchk (ignoring autobuild failures overnight), and we have a failure at taking the gnu library tests out of the gcc build tree - they don't seem to be able to run against an installed library (and not entirely certain about license on these, either). > - IPv6 > - like C++, though not as urgent IPv6 and C++ share something: we think they're supported, in compatible form, in current distros today. It would be a shame not to be able to go ahead and include something that's already working into the spec. But we can't /prove/ they're compatible yet... > - TLS > - Can we live without it? > - Needed for NPTL which we really want, but requiring > it requires TLS in implementation. > > - Who other than RH are willing to deploy it. > - Needs 2.6 (not released), or 2.4 backport. Just doesn't look ready, i.e. doesn't meet the "best practice" requirement today. > - AIO > - No choice really as no good > implementation yet, nor will > there be for 2.6. More of a > 2.8 thing from what I've heard. > Also heard kernel developers believe no real > demand for all of aio. > Maybe we need to help organise? I think the part of aio that a minor insignificant part of the software market needs ("databases") is exactly the part that's being addressed in 2.6. But it's quite true that this is not deployed yet, and may not be in a timeframe that makes it possible. I'm guessing that the forthcoming RH EL 3.0 release, which is supposed to have a two-year run cycle, will not be 2.6 based. Again, since 2.6 is required, this fails the "best practice" requirement. > - SUSv3 > - No tests, but much like C++ > should not necessarily stop us > from including in spec > - Man page work *must* be done There seem to be unknowns here also in regards to groupings - does a reference to SUSv3 "accidentally" require more or less than we expect with a chance of leading to more of the kind of confusion we saw over i18n inclusion for 1.3. > - NPTL > - See TLS > > 2. Various options > i. Keep cut-of-date > - accept less functionality in 2.0 > > - what is acceptable? > > - next release not for another year (better to delay by > a couple of months to get more in?) For me, I think this is the crux of the concern. Do we have a clear picture that an LSB 2.0 we could put to bed in a few weeks, even sliding somewhat past Oct 17, would meet the needs of the software developer community out through mid-2005, and be a significant enough step forward that distros take the trouble to support it. I get a sense that proper C++ support is important enough that it might actually be true. From taggart at carmen.fc.hp.com Wed Oct 8 09:03:45 2003 From: taggart at carmen.fc.hp.com (Matt Taggart) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] October 8 lsb-sc minutes Message-ID: <20031008160345.2C05D37D64@carmen.fc.hp.com> lsb-sc confcall Tuesday, October 8, 2003 Attendees: Matt Taggart, Mats Wichmann, Marvin Heffler, Kevin Caunt, Chris Yeoh, Stuart Anderson, George Kraft IV Minutes: NOTE: I just wrote down what I heard, some things might be unclear please reply with additional explaination/comments Discuss delaying 2.0 due to the following issues SUSv3 tests Andrew mentioned TOG's SUSv3 efforts are taking a few man years and they still aren't done, for us to wait on SUSv3 tests would be a very long wait If we move to v3 do we lose testing coverage? gk4 had a long answer Are the distros v3 based today? Rather than audit, chris proposed a top-down test run and see what breaks. We expect the distros will all break the same way, and the only variance would be between different versions of glibc. This would help, but isn't perfect. This method was used for 1.x for SUSv2 stuff. A man page audit is under way What assertions are being added? We can't really answer that today Chris thinks that maybe symbol versioning might help protect us We don't know when we're going to get tests from TOG, if we proceed we're taking a risk that we won't have tests c++ tests current tests build in the upstream tree and it's hard to split out gk4 spent some time trying to pull them out, he has not reviewed the content or coverage mats speculates that the tests work pretty well on the version of gcc they are released with, but taking cvs HEAD tests and running against older versions might have failures What's worse slip or release and have problems? slipping is ok, but we need to have a plan on how we're going to complete the work FHS2.3 If we slip, this would give us more times to shake things out Distros seem to be ok with the new /media but maybe not /srv The rest of the change are mostly to bring the FHS into line with what the LSB is doing today. Stuart pointed out that FHS also operates on a "we'll release it when it's done" schedule. Chris thinks that if there are still issues with the new stuff that it could be dropped in order to release 2.3. Chris thinks updating the tests won't be too much work. We need to map out who's going to do the tests to make sure they're not double booked. Ask ajosey to do this. pthreads Kevin has a RHEL3+patches system that he's trying to get a baseline on taggart asked if this is new functionality violates our "best practice" criteria. gk4 pointed out that the spec should already cover this, we just need to make sure it supports both models We have tests today, they're just not run. Would we add these tests to 2.0? No Does Debian support NPTL yet? taggart doesn't think so Currently requires a 2.6 kernel or a 2.4 backport Side discussions: New tests vsw4(X11 tests) 11% more tests What about ISO? Does delaying 2.0 hurt that somehow? gk4 says he's not worried about it, it's less important than keeping the distros up to date and talking to ISVs Next meeting will use the AppBat time slot on Thursday(tommorrow) 8am PDT / 9 MDT / 10 CDT/ 11 am EDT / 1am AEST(Fri) Use gk4's dial-in number 1-877-930-0325 122024 Thanks, -- Matt Taggart Linux and Open Source Lab taggart@fc.hp.com Hewlett-Packard From gk4 at austin.ibm.com Wed Oct 8 13:47:38 2003 From: gk4 at austin.ibm.com (George Kraft) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] lsb-sc mailing list In-Reply-To: <20031007211936.44C4237D1C@carmen.fc.hp.com> References: <20031007211936.44C4237D1C@carmen.fc.hp.com> Message-ID: <1065646058.2235.796.camel@gkraft4> > project as open as possible but I'd be ok with a closed lsb-sc list > as long as it's use is minimized to things that _have_ to be private. The SC distribution list is just to narrow the scope of recipients, and it is to be kept public per the FSG workgroup guidelines. :-) -- George (gk4) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.linux-foundation.org/pipermail/lsb-sc/attachments/20031008/994b4ecd/attachment.pgp From taggart at carmen.fc.hp.com Thu Oct 9 09:07:55 2003 From: taggart at carmen.fc.hp.com (Matt Taggart) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] October 9 minutes Message-ID: <20031009160756.8F22937D1C@carmen.fc.hp.com> lsb-sc confcall Tuesday, October 9, 2003 Attendees: Mats Wichmann, Matt Taggart, Marvin Heffler, Chris Yeoh, Kevin Caunt, Stuart Anderson, Doug Beattie, George Kraft IV Minutes: Brief AIO discussion What's absolutely required for 2.0? c++ is a must Stuart might have an intern that would work on this Upstream tests The plan is to split out the upstream tests so they can run stand-alone. We can run the test suites in tree and determine the coverage without needing to split out the tests. If the coverage isn't adequate then there's no need to wait glibc 2.3 changes is a must Mats noted that Debian folks discovered that glibc 2.3 comes with a new POSIX version that causes new compiles of things like coreutils to have different behaviors(they get rid of deprecated stuff, etc) We need to build and run the test suites against the a new glibc 2.3 system SUSv3 is a want We think newer glibc's still support v2, chris will test We don't have enough info set a schedule, we'll discuss on the 20th Actions Chris will run the test suites on new glibc to look for issues gk4 will run the c++ upstream tests to determine coverage and report back. Assuming the coverage is good then he'll start on making the tests run stand-alone stuart will enhance libchk and send mail upstream there are additional validation steps stuart needs to do, one is test against against newer upstream gcc releases taggart will contact upstream with a request to make the c++ tests build and run outside of the gcc tree. dejagnu is fine, we just marvin, kevin will work on SUSv3 man pages and help gk4 where needed mats, stuart are traveling the next week Next meeting on October 20th 8am PDT / 9 MDT / 10 CDT/ 11 am EDT / 1am AEST(Fri) Use gk4's dial-in number 1-877-930-0325 122024 -- Matt Taggart Linux and Open Source Lab taggart@fc.hp.com Hewlett-Packard From gk4 at austin.ibm.com Fri Oct 10 06:47:25 2003 From: gk4 at austin.ibm.com (George Kraft) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] Re: [FWD:Options for OpenI18N spec for ISO Linux] In-Reply-To: <200310101132.UAA01549@kayacon.jrd.dec.com> References: <200310101132.UAA01549@kayacon.jrd.dec.com> Message-ID: <1065793644.18461.46.camel@gkraft4> Yoichi, Your specifications regarding locales and environment variables are supported by SUS, but your input method requirement is not and we are unsure of its implementation availability; therefore, I would recommend the LSB not include it. However, that is a collective decision for the LSB SC. ISO has recommended that the LSB be assigned a major number with each of its separate specifications being given a minor number. For example: ISO/IEC 1234-1, Information technology - Linux Standard Base - Part 1: Generic ISO/IEC 1234-2, Information technology - Linux Standard Base - Part 2: IA32 ISO/IEC 1234-3, Information technology - Linux Standard Base - Part 3: IA64 I recommend that the FSG make a request to ISO to obtain another major number for the OpenI18N specifications. This will keep things separate for the purpose of ownership and maintenance. "ISO Linux" can be a group of major numbered specifications. Best regards, George (gk4) On Fri, 2003-10-10 at 06:32, Yoichi Suehiro wrote: > George, Stuart, > > We'd like to know whether any of the three options Hideki listed below > is acceptable to LSB. If none of them are acceptable, > OpenI18N will seek for other approaches. > > As Hideki wrote, we understand that policies are different between > LSB and OpenI18N. We have no intention to embarrass LSB on this > but just want to know if any compromise is possible for ISO Linux. > > Thanks and best regards, > Yoichi > > ------- Forwarded Message > > Date: Tue, 30 Sep 2003 14:37:01 +0900 > From: Yoichi Suehiro > To: gk4@austin.ibm.com > cc: hiura@openi18n.org, kido@openi18n.org, hchapman@us.ibm.com, > SHOJI@jp.ibm.com, suehiro@jrd.dec.com > Subject: Options for OpenI18N spec for ISO Linux > > George, > > Since it is September 30th today, I'm sending you again our OpenI18N input. > > Please take a look at the attached message I sent. > Do you think this type of non-API specification can be included > in ISO Linux draft? Any suggestion or comments? > > What is your opinion about the options Hideki presented in his mail > that is also attached below. > > Thanks and regards, > Yoichi > > - ------- Forwarded Message > > Date: Thu, 25 Sep 2003 11:08:36 +0900 > From: Yoichi Suehiro > To: openi18n-sc@openi18n.org > cc: gk4@austin.ibm.com, nick@usenix.org, suehiro@jrd.dec.com > Subject: [openi18n-sc:1035] Re: Options for OpenI18N spec for ISO Linux > > I tried to write up OpenI18N requirements to be accompanied > with LSB. The requirements have been relaxed and > the description has been simplified. > > Yoichi > ==== > n. Internationalization > > n.n Locales > > Conforming implementations shall support the POSIX and C locales > as specified in the Single UNIX Specification. > Conforming implementations may provide additional locales. > > The localedef utility shall have the capability to accept charmap > for UTF-8, at least. > > Conforming implementations shall document supported locales on a system. > > n.n Environment Variables > > Conforming implementation shall provide the following environment variables > that are relevant to the operation of internationalized interfaces or > internationalized commands and utilities. > > LANG > LC_ALL > LC_COLLATE > LC_CTYPE > LC_MESSAGES > LC_MONETARY > LC_NUMERIC > LC_TIME > NLSPATH > > The usage and the semantics of these environment variables shall be > the same as the description in the Single UNIX Specification (SUS). > > n.n Input Methods > > Conforming implementations shall provide means for users to input > all of the characters supported in each locale. > > Conforming implementations should have a capability to allow users > to input whole repertoire of [Unicode 3.0]. > > n.n Output Methods > > Conforming implementations should provide means for users to output > all of the characters supported in each locale. > > Conforming implementations should have a capability to allow users > to ouput the following collections of UCS implementation level 1 > defined in [ISO 10646-1]. > > [put here a copy of character collection from OpenI18N 1.3] > > [END] > > ============================================================================ > Date: Thu, 18 Sep 2003 12:29:09 -0700 (PDT) > From: hiura@openi18n.org (Hideki Hiura) > Subject: [openi18n-sc:1030] Options for OpenI18N spec for ISO Linux > To: openi18n-sc@openi18n.org, gk4@austin.ibm.com, nick@usenix.org > > This is the AI from yesterday's SC meeting, to summarize > the problems and possible options for global ready ISO Linux. > > In regard with ISO Linux discussion, the following has been the > basic stance, however, we are now all aware that this won't be > possible without some changes somewhere. > > > From: Nick Stoughton > > However we would like to ensure that Scott's equation: > > Real World Linux = LSB = ISO Linux > > continues to hold true ... that is, nothing should go into ISO Linux > > that is not in the LSB; it IS the LSB (and specifically LSB 2.0 is the > > version that will be submitted) that will be ISO Linux. > > If you have interfaces that you believe should be part of ISO Linux, > > then they need to be added to LSB 2.0. > > -- > > Nick > > Scott's equation > Real World Linux = LSB = ISO Linux > should really mean > Real World Wide Linux = LSB(integrated all OpenI18N) = ISO Linux > however, If LSB does not integrated what OpenI18N specified, > the equation has to be modified as > > Real World Linux = LSB > Real World Wide Linux = LSB + OpenI18N = ISO Linux > > The problem we are straggling with is the policy difference > between LSB and OpenI18N, as follows; > > LSB: ABI standard, only specify what exist in upstream. > OpenI18N: Behavioral standard, specify what should system provide. > > Both policy are perfectly fine. The problem arises because we tried > to merge two distinctive things. > > This difference makes current LSB virtually impossible to incorporate > some part of OpenI18N spec, without modifying its policy, and it makes > LSB alone won't be satisfactory for global market. > > So options presented during discussion for ISO Linux are: > > 1. Modify LSB as Behavioral standard to include OepnI18N. > (unlikely possible...just listed here for comparison) > 2. Modify LSB to allow including Behavioral standard as > separate section or appendix or some convenient form > to include OpenI18N. > 3. Create docket which co-bundles LSB and OpenI18N for ISO > PAS submission. > > Any idea? What your take? > > Hideki > > > - ------- End of Forwarded Message > > > > ------- End of Forwarded Message -- George (gk4) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.linux-foundation.org/pipermail/lsb-sc/attachments/20031010/d078b2ec/attachment.pgp From suehiro at jrd.dec.com Sun Oct 12 15:26:54 2003 From: suehiro at jrd.dec.com (Yoichi Suehiro) Date: Thu Jul 12 13:07:52 2007 Subject: [Lsb-sc] Re: [FWD:Options for OpenI18N spec for ISO Linux] In-Reply-To: Your message of "10 Oct 2003 08:47:25 EST." <1065793644.18461.46.camel@gkraft4> Message-ID: <200310122226.HAA26429@kayacon.jrd.dec.com> George, Thanks for your response. I'll wait for the decision. Regards, Yoichi === | Yoichi, | | Your specifications regarding locales and environment variables are | supported by SUS, but your input method requirement is not and we are | unsure of its implementation availability; therefore, I would recommend | the LSB not include it. However, that is a collective decision for the | LSB SC. | | ISO has recommended that the LSB be assigned a major number with each of | its separate specifications being given a minor number. For example: | | ISO/IEC 1234-1, Information technology - Linux Standard Base - Part 1: | Generic | ISO/IEC 1234-2, Information technology - Linux Standard Base - Part 2: | IA32 | ISO/IEC 1234-3, Information technology - Linux Standard Base - Part 3: | IA64 | | I recommend that the FSG make a request to ISO to obtain another major | number for the OpenI18N specifications. This will keep things separate | for the purpose of ownership and maintenance. "ISO Linux" can be a | group of major numbered specifications. | | Best regards, | | George (gk4) |