Enclosed please find the minutes from the May 5, 2017 IBIS Editorial Task Group
meeting. Comments and suggestions are welcome.
- MM
======================================================================
IBIS EDITORIAL TASK GROUP
http://www.ibis.org/Editorial_wip/ ;
Mailing list: ibis-editorial@xxxxxxxxxxxxx
Archives at //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.
