====================================================================== IBIS EDITORIAL TASK GROUP http://www.ibis.org/Editorial_wip/ Mailing list: ibis-editorial@freelists.org Archives at http://www.freelists.org/archive/ibis-editorial/ ====================================================================== Attendees from May 5 Meeting (* means attended at least using audio) ANSYS Curtis Clark Intel Corp. Michael Mirmak* Keysight Technologies Radek Biernacki*, Ming Yan Mentor Graphics Arpad Muranyi* Micron Technology Justin Butterfield, Randy Wolff Signal Integrity Software Walter Katz, Mike LaBonte* Teraspeed Labs Bob Ross* Michael Mirmak convened the meeting. No patents were declared. Mike LaBonte moved to approve the April 28 minutes; Bob Ross seconded. The minutes were approved with no objections. In a previous meeting, Mike took the AR to upload his files to the Task Group website. This has been done. No other ARs were mentioned. Bob raised an open: has has found three sections of the IBIS document where we don't have file name restrictions on string length; this includes .AMI files and multi-lingual files. His concern is consistency with data line length for the rest of the IBIS files. Mike added that, when naming things, there are two ways to hit length limits under IBIS today. Bob pointed out that page 192 of IBIS 6.1 explicitly omits a line length limit for the contents of the .ami file. This should be addressed as a separate issue. Summarizing recent work on BIRD186, Mike noted that Radek Biernacki and Bob agreed on use of "file" vs. "file name". Mike would be willing to create a BIRD by scanning existing IBIS 6.1 text and making the appropriate edits. Bob responded that there are two things to fix: first is the requirements section, which can be easily updated. A new Section 3 is the second area to address. Bob noted that a relative path can be pointing to a location five directories down, and the specification language needs to address this. Radek asked whether we finalized rules for treatment of slash and backslash. Arpad Muranyi noted that, last week, he asked a similar question about .\ or \ - the conclusion then was that starting with a \ was prohibited. Bob disagreed, asking whether we explicitly prohibited starting paths with a slash. Arpad replied that we should be considering prohibiting use of .. or . in the path at all. This prevents accidentally "going up" (traversing upward toward the root) the directory tree. Radek advocated prohibiting the .\ sequence. Arpad reminded the team that Walter intended to allow only access to lower directories, not ones closer to the root. Radek noted that .. by itself (without slash) is acceptable in a directory name. Mike stated that interconnect files with references to files in the "next directory over" may be needed. Therefore, the specification needs ..\ as a sequence. Radek replied this is dangerous; Mike agreed. Radek added that we don't want to impose a particular directory structure. Michael asked whether the issue is use of .. or ..\ or ..\..\..\ etc.? Radek suggested the BIRD prohibit any sequence of . and \ including .\ - the sequence to be avoided is .\ at all. Bob stated that the problem is allowing . in file names and allowing slash(/) as well to permit directories. That's the fundamental source of controversy. Radek replied that we can just prohibit .\ as a sequence. Bob added that he doesn't like the "relative path" term, and reminded the team of Walter's prohibition on ..\ in the original BIRD. Declaring it illegal, even if allowed by OS, is an explicit goal Mike moved to change ".." to "." in the sentence: The character sequence “../” is not permitted, except that it is permitted if generated by the EDA tool. Bob seconded. Arpad and Radek suggested adjustments to add a parenthetical statement. The proposed final sentence would be: The character sequence “./” (which covers the sequence “../”) is not permitted, except that it is permitted if generated by the EDA tool. Mike and Bob accepted this change to the motion, which carried without objection. Radek noted that the entire section needs to be changed to use "path" rather than "file name". Mike noted that he has a concern about the last clause of the sentence ("except that it is permitted..."). Bob added that we are still using the term "directory" without defining it. He additionally would remove the 64-character limit pertaining to "directory" and "file name". Michael replied that we need to clarify the words, "directory", "path", and "file name". Mike has addded the word "directory" to the BIRD. Mike accepted the AR to update Figure 1 to indicate the "directory". He may add a second figure to ensure that no single figure is too cluttered. Bob stated that no one refers to directory-plus-file name as a "relative path". He would never expect the industry to use "relative path" where a filename is used. The definition of "file" is ostensive. Bob suggested the phrase, "for the purposes of definition in this document" be used in places where industry usage differ. Bob accepted the AR to fold the three new definitions into Draft 8. Mike noted that, of the 44 "file name" occurences in IBIS 6.1, only 6 (six) would involve "stem"; those aren't difficult to address in a revised BIRD. Mike took the AR to make the changes and pass the BIRD to Bob. Radek noted that Microsoft* Windows does not allow, but Linux does permit, access to a file called "aaa../bb". We can safely disallow it in the BIRD. Arpad stated that the dot character has two different meanings: an extension separator vs. directory indicator. Using the .. sequence may imply an empty string extension. Michael noted that several BIRDs are now being held up by the changes in BIRD186. He reminded the team of the need to make the fixes as rapidly as possible to continue other work. Mike asked whether it was too soon to call for BIRD approval in the Friday Open Forum meeting. Bob answered, yes. He suggested that the text of BIRD189 be changed to use "stem" where "base name" appears. Mike asked whether we could resolve BIRD186 after voting on BIRD189. Mike moved to adjourn. Bob seconded the motion. The meeting adjourned without objection.