Disallow commas and other punctuation in RNAME etc #333

jmarshall · 2018-08-23T15:25:31Z

The suggestion here is to disallow \ , "'`` () <> [] {}, i.e., backslashes, commas, various quote marks, and various brackets. Hopefully this is consistent with the statistics listed in #291. Additional counts for some of these characters would be useful — see #333 (comment) below.

The existing spec uses regular expressions containing ASCII ranges, which is fairly opaque. This PR lists the punctuation characters explicitly and then invents some extra character class notation to refer to the set of allowed characters succinctly and hopefully clearly:

yfarjoun · 2018-09-17T14:00:00Z

I'm assuming that , is in the list because otherwise SA and OA are broken, despite being present at some references.

What will the folks that have , in their ref-names do? Should the implementations enable (with warnings) these characters or not?

jmarshall · 2018-09-17T14:05:18Z

I mean to re-collect the statistics on this PR, but IIRC all the commas observed in the various repositories are from one malformatted file, as noted in #291 (comment). So such folks have not been observed to exist.

Disallow \ , "`' ()[]{}<> punctuation characters in reference sequence names. Commas and angle brackets are used to delimit refnames in other SAM fields (e.g. SA) and in VCF files, and restricting these other characters facilitates future delimiter and quoting syntax. Statistics gathered from various reference sequence archives suggest that these characters appear vanishingly infrequently in refnames in existing files in the wild. Add previously omitted SQ-AN history note.

jmarshall · 2018-09-19T12:11:43Z

Previous discussion of punctuation characters in RNAMEs can be found in #124 (HLA and colons), #167 (VCF and commas/equals), #220 (SQ-AN; statistics), #258 (VCF and HLA/colons), #291 (VCF breakends; statistics).

This table collects the statistics of punctuation character counts from various archives of reference FASTA files:

Char	Sanger (Rob)	Broad (Yossi)	ENA (Cristina)	Notes
`!`	.	.	.
`"`	.	.	.	Propose to disallow
`#`	203	12	16927
`$`	.	.	.
`%`	203	.	.
`&`	.	.	.
`'`	.	.	.	Propose to disallow
`(`	.	.	.	Propose to disallow
`)`	.	.	.	Propose to disallow
`*`	525	527	1	Used in some HLA alleles
`+`	1	.	.
`,`	496	357	231	Want to disallow
`-`	154226	1451132	122563947
`.`	1826561	1492749	521540419
`/`	.	86114	236951
`:`	1577	233731	30181	Can't disallow, used in HLA alleles
`;`	.	.	72892	Might like to disallow, but many in ENA data
`<`	.	.	.	Propose to disallow
`=`	26	2034	186611
`>`	.	.	.	Propose to disallow
`?`	.	.	.
`@`	.	17	3713
`[`	.	.	.	Propose to disallow
`\`	.	.	0	Propose to disallow
`]`	.	.	.	Propose to disallow
`^`	.	.	.
`_`	4961932	.	.
`	.	.	.	Propose to disallow
`{`	.	.	.	Propose to disallow
\|	1098333	1735713	949	Can't disallow, historically used in NCBI FASTA
`}`	.	.	.	Propose to disallow
`~`	.	.	.

. indicates counts not reported. It would be very good to fill in the gaps for the characters proposed to be disallowed: in particular quotes and the various bracket characters. [Noted below for Broad and IIRC in phone meetings for the other centres that unreported . indicates a zero count.]

Re commas, @daviesrob reported that all the commas he observed originate from one malformatted file. @yfarjoun, @cyenyxe: Is something similar the case for the other two repositories?

jmarshall · 2018-09-19T14:56:22Z

What will the folks that have , [etc] in their ref-names do? Should the implementations [allow] (with warnings) these characters or not?

I was previously thinking it was important that implementations shouldn't need to enforce several different subsets of characters, and therefore that we shouldn't mark this change via HD-VN. Now I don't think that's nuanced enough. Based on conversation at last month's meeting, the considerations are:

Implementations that would like to validate the subset of RNAME characters shouldn't need to enforce several different subsets;
Implementations shouldn't gratuitously reject existing data files containing acceptable at the time but now disallowed RNAME characters;
Implementations need to be able to signal their displeasure with disallowed RNAME characters if they are seen in newly-created data files. (Otherwise people will just carry on (mis)using them.)

So implementations should accept commas etc for HD-VN≤1.5 but diagnose commas etc for HD-VN≥1.6. (Assuming that they essentially copy VN when copying records around but emit the current spec VN when creating new data files.) It would be up to the implementation whether this means silence for ≤ 1.5 and a warning for ≥ 1.6, or warning≤1.5 and error≥1.6, or etc. (The SQ-AN subset was more restricted prior to this PR, but I would suggest that there is no point enforcing this for ≤1.5.)

If a ≤1.5 file has a , in an RNAME then this should IMHO be accepted (perhaps with a warning) as nothing will go wrong immediately and it is useful to be able to process the data. Problems would ensue if that RNAME was propagated to an SA or OA tag, and IMHO it should be up to the implementation whether to accept, warn, or reject it at that point. (The statistics collected show that this scenario would be vanishingly rare.)

Probably VN:1.6 is rare enough in the wild that using it to signal the intention to comply with this restricted RNAME subset is fine. Or we might perhaps want to bump the spec to VN:1.7 to signal this.

If others agree with this ≤1.5 / ≥1.6 approach, I'll add text to this effect to the history appendix entry.

Consideration (1) means that we have only this one chance to get the subset selection right!

Disallow \ , "`' ()[]{}<> punctuation characters in reference sequence names. Commas and angle brackets are used to delimit refnames in other SAM fields (e.g. SA) and in VCF files, and restricting these other characters facilitates future delimiter and quoting syntax. Statistics gathered from various reference sequence archives suggest that these characters appear vanishingly infrequently in refnames in existing files in the wild. Add previously omitted SQ-AN history note.

yfarjoun · 2018-09-20T13:40:46Z

I'm OK with outlawing #, [, ], and the comma , (and all the other ones that there are no counts for)

In the end it's only 3 references that have them, and i think that we can deal.
the other operators we do not have in our references...so unreported == 0 (from Broad)

I'd like to note that * is in hg38...so I think the ship has sailed FAR with that one.

jkbonfield · 2018-09-20T14:15:20Z

Do we need to extend the regexp notation?

My interpretation of POSIX is we'd normally use things like [[:alpha:]] rather than [:alpha:] when inside a character class itself, and thus can extend them. Thus [[:alpha:][:digit:]] is equivalent to [[:alnum:]], (or also to [:alnum:]?).

This in turn means if we chose the left hand side of the rname as [:rname:] class, rather than the right (note we don't say which it is - it's just "this" in the spec now), then we can define the RNAME field as matching [[:rname:]][*=[:rname:]]*. Ugly, but I think it's valid without inventing new syntax.

jkbonfield · 2018-09-20T14:20:59Z

I like the inclusion of appendix A - it's not specification, but guidance on tool chain usage which feels appropriate. Do we also want to expand on potential disambiguation techniques? Eg given we're outlawing curly braces, we could also permit {rname}:1-2 to be equivalent to rname:1-2, thus permitting {foo:100-200} vs {foo}:100-200 as disambiguation syntax. Again this isn't a specification requirement, but a hint for a new mechanism

yfarjoun · 2018-09-20T14:38:22Z

I like the proposed hint for disambiguation. it should probably be put into the spec so that different tools can all use it.

jkbonfield · 2018-10-15T16:02:21Z

For completeness here, if I recall in the last File Formats meeting @jmarshall explained the logic for a new regex syntax. My understanding is it is a preference to define the characters that may be used, with an exception for the first character, rather than swapping these around purely for the convenience of sticking with standard regexps.

Really this is just a case of regexp being a poor choice compared to a grammar. I'm not entirely convinced with the argument, but I can see it has some benefit too so I'll accept it if others are like minded.

Apart from that foible, I'm happy with this PR.

jmarshall · 2018-10-15T16:30:17Z

I think in the previous meeting we agreed with #333 (comment) so I'll add a bit talking about VN foibles. And that I'll expand the appendix to suggest a convention of {rname}:1-2 syntax.

The thing about regexp syntax comes down to clarity of exposition. For me, the downside of inventing our own tiny piece of ad hoc regexp-related syntax is outweighed by upside of being able to express the set of rname characters directly:

in text: any printable ASCII characters in the range [!-~] apart from backslashes, commas, quotation marks, and brackets—i.e., apart from [the exact characters]
in the exact voluminous regexp
in a legible pseudo-regexp that shows the foible of “must not start with * or =” directly.

I think it's clear that “we write this set of characters” refers to the set described in (1), and even if that's not clear to a particular reader the meaning is made clear by having (2) there too.

I tried it both ways around (and several other ways too) and I believe that this way leads to the clearest exposition, which is why it's in the proposal. James's understanding described in the previous comment is correct; people who remain displeased by the idea of inventing ad hoc regexp syntax should workshop this themselves and see if they can come up with something clearer. 😄

yfarjoun · 2018-12-05T18:36:56Z

While we are here...should we protect the sequence name unmapped from ever being used? in GATK we use this to point to the unmapped & unplaced reads...it would break if someone were to use unmapped as a name of a sequence...

jkbonfield · 2018-12-06T09:29:12Z

Hmm, that feels a bit too implementation specific!

I was wondering though recently about classes of names that we may wish to reserve for specific purposes. I'd like a way of inventing reference names, eg by crude hash based or minimiser based denovo assembly of unmapped data. These would need entries in the SQ headers too, and have to be named.

Eg * is the "unavailable" read name. Maybe *unmapped could be used, so we say all reads starting with * are implementation defined (apart from * itself). Similarly *1 for a reference name would be suitable to name a fake reference created purely for purposes of data compression. (Edit: I'd probably do that in CRAM only and turn back to unmapped again on decode, but possible bleed through via old software is always a possibility.)

yfarjoun · 2018-12-06T13:29:52Z

given that htsget is currently grappling with how to access unplaced reads, I don't think that it is implementation specific.... #320

jmarshall · 2018-12-06T13:49:03Z

should we protect the sequence name unmapped from ever being used

This is a question about in-band vs. out-of-band signalling (i.e., do we allow for special values that are syntactically the same as normal values). In programming languages, this is called reserved words vs. identifiers, and the usual approaches are grandfathering in the list of reserved words right from the start or adding new reserved words by using distinguishing syntax (e.g. a leading _ that's not allowed for normal identifiers, or having some namespace syntax like ::).

IMHO it's very late in the day to be thinking about adding some reserved words to our RNAME rules. Particularly as SAM has always reserved all RNAMEs starting with * or =, so we already have leading character distinguishing syntax. So I'm afraid IMHO GATK should be using *unmapped or =unmapped to do this in a reasonable way.

As for htsget:— there has been a discussion about whether to use SAM's already distinguished-syntax * for unplaced unmapped reads queries, or whether to use a different URL query parameter name so as to be truly distinctive and out-of-band. What you can be sure of is that htsget won't be considering using anything in-band like an otherwise undistinguished referenceName=unmapped. 😄

jkbonfield · 2018-12-06T14:22:05Z

Technically SAM doesn't reserve words starting with "*" or "=", but words that are entirely "*" or "=".
My suggestion though is to relax that slightly, as John describes above.

I think "implementation defined" is a good way of dealing with them too. So we can say "*" and "=" have reserved meanings, anything starting "*" or "=" is implementation dependent, and everyone else you have to honour as valid user data.

I've given a use case I hope to put into practice already here - fake references for data clustering purposes.

jmarshall · 2018-12-06T14:32:31Z

The current spec has long said that @SQ-SN values must match [!-)+-<>-~][!-~]*.

You are correct that the RNAME and RNEXT fields assign particular meanings to words that are in their entirety "*" or "=". However due to that regexp the spec also reserves all RNAMEs starting with * or = — though it doesn't yet define any meanings for such RNAMEs (other than "*" and "=").

jkbonfield · 2018-12-06T14:56:39Z

Ah yes, you're correct. I hadn't spotted * was missing from the RNAME regex. This is inherently the problem of having negated regexps done this way; it's hard to remember my ASCII collating order to know what is between ) and +. The new regexp is a huge improvement in this regard too. :-)

* implementing the spec change in samtools/hts-specs#333 * this disallows a number of characters from reference sequence names, these are characters like ',' which do not appear in standard references and which cause parsing issues if they are allowed

jmarshall · 2018-12-19T17:37:09Z

I think in the previous meeting we agreed with #333 (comment) so I'll add a bit talking about VN foibles. And that I'll expand the appendix to suggest a convention of {rname}:1-2 syntax.

I've just pushed a draft of those two things. I think we're all in agreement on the basic thrust of this PR, so once that's reviewed and wordsmithed, I think this is ready to merge!

It wasn't that easy to compose something useful to say about the VN foibles and note that contrary to the suggested text in this latest commit, samtools/htsjdk#1238 as merged strictly enforces the RNAME regexp regardless of the input file's @HD-VN value. Hmmm…

jmarshall · 2019-01-10T12:36:57Z

@jkbonfield @yfarjoun — please review this last commit about {rname}:1-2 delimiter syntax and VN.

If we agree with adding this to VN:1.6 (rather than bumping to a new VN:1.7), I think this is ready for merging.

jkbonfield · 2019-01-10T13:57:45Z

I'm fine with it and if I recall the bracing style matches the in the languishing samtools/htslib#708 PR.

I don't think we need a version number bump (but I wouldn't feel overly concerned if we decided it warranted it).

Disallow \ , "`' ()[]{}<> punctuation characters in reference sequence names. Commas and angle brackets are used to delimit refnames in other SAM fields (e.g. SA) and in VCF files, and restricting these other characters facilitates future delimiter and quoting syntax. Statistics gathered from various reference sequence archives suggest that these characters appear vanishingly infrequently in refnames in existing files in the wild. Fixes the SAM aspects of samtools#124, samtools#167, samtools#258, and samtools#291. Add appendix describing parsing `name:beg-end` when name allows colons: pseudocode description of algorithm to detect ambiguous input, as proposed in a comment on samtools#124; suggest also accepting an alternative `{name}:beg-end` delimited notation. Add previously omitted SQ-AN history note.

jmarshall · 2019-01-11T14:34:39Z

Rebased on to current master.

It appears that we've never really particularly discussed the suggested candidates for punctuation to disallow!

After removing the characters disallowed by this pull request, we are left with the following accepted RNAME punctuation characters:

. _ - + = @ # * / : | ; Characters seen in the wild that are of (mostly) obvious utility in naming

! $ % & ? ^ ~ Characters not seen in the wild and of dubious utility in naming

Of the dubious ones only % (203 at Sanger) has a non-zero count in the table in #333 (comment).

There would be something to be gained from disallowing some of these dubious characters (^$ as regexp metacharacters or ^chr5 not-chr-5 notation; ?&% in URLs; ! in C-Shell or not- notation). However it also behooves us to have understandable rules about what characters are not allowed and not to arbitrarily restrict what has been allowed for years (chr5??! in an incomplete assembly? 😄).

So I mention this for completeness, and propose to merge this as is, with the somewhat clear and memorable rule being: backslash-comma-quotes-brackets forbidden…

jkbonfield · 2019-01-11T16:14:37Z

It's a great step forward, and if we later rethink it further it can be a separate PR. However realistically I'm not so worried about shell and regexp metacharacters as they can be escaped. The main concern we had was actual functionality of the specification being broken - eg commas being used elsewhere in strings that contain names, angle brackets in VCF contig names, etc.

Besides, if we forbid ? then how am I going to get my ANSI trigraphs through now? ;-)

jmarshall · 2019-01-11T17:05:28Z

It is indeed a great step forward. I really don't want to restrict it further in future though, as that wouldn't be fair to users or to implementations (#333 (comment) consideration (1)).

Disallow \ , "`' ()[]{}<> punctuation characters in reference sequence names. Commas and angle brackets are used to delimit refnames in other SAM fields (e.g. SA) and in VCF files, and restricting these other characters facilitates future delimiter and quoting syntax. Statistics gathered from various reference sequence archives suggest that these characters appear vanishingly infrequently in refnames in existing files in the wild. Fixes the SAM aspects of samtools#124, samtools#167, samtools#258, and samtools#291. Add appendix describing parsing `name:beg-end` when name allows colons: pseudocode description of algorithm to detect ambiguous input, as proposed in a comment on samtools#124; suggest also accepting an alternative `{name}:beg-end` delimited notation. Add previously omitted SQ-AN history note.

Disallow \ , "`' (){} punctuation characters in VCF contig IDs. The characters []<> were already disallowed in VCF; this also relaxes the prohibition of * to merely disallowing initial *. Statistics gathered from various reference sequence archives suggest that the characters restricted appear vanishingly infrequently in SAM reference sequence names in existing files in the wild. To the extent that all contig IDs in VCF files come from corresponding SAM/BAM files, this means there is little concern about making the same restrictions in VCF contig IDs. Fixes samtools#124 and fixes samtools#167 for VCF; their SAM aspects were previously fixed by PR samtools#333.

….file to sanitize fasta file IDs fasta ID is sanitized for picard CreateSequenceDictionary to adhere to character set restrictions in SAM/BAM RNAME spec. see: samtools/hts-specs#333 Roll back test input now that we are doing the sanitization. As of this commit, sanitization is only performed on fasta files destined for CreateSequenceDictionary

* update picard 2.18.11 -> 2.20.3 * remove certain characters from unit test input fasta that are disallowed by picard commas, single quotes, etc. * compare only reads in sam post-depletion compare only reads in sam post-depletion, allowing us to ignore header differences due to varying versions of picard/samtools/htslib; remove related permutations of expected output from tests * update expected output for depletion db build tests * use regex to allow for flexible header comparison in picard test * In TestFastqBam, resolve longstanding brittle test case add new test assertion, "assertEqualSamHeaders" to address this inline ToDo for TestFastqBam(): "Note for developers: if you're fixing the tests to handle non-bugs (ie our testing here is too brittle), let's just replace a lot of this in the future with code that just reads the header, sorts it, and tests for equality of sorted values in the RG line (and stricter equality in the non-header lines). This is kind of hacky." * add debug statements to install-viral-ngs.sh script add debug statements to install-viral-ngs.sh Docker script * install viral-ngs dependencies to separate conda env from base env * let's try conda 4.7.10 * unpin conda-build and jinja2 * bump conda-build * do not install gcc * pin CONDA_R=3.4.1 * conda build --debug * let's try pinning R to the latest since something is pulling it in? * remove --debug from conda-build * bump r version required by GATK 3.8 conda package * r-base * r 3.5.1 * matplotlib 2.2.0 -> 2.2.4 * bedtools 2.27.1 -> 2.28.0 * blast 2.6.0 -> 2.7.1 * roll back test input to state of origin/master; add functions to util.file to sanitize fasta file IDs fasta ID is sanitized for picard CreateSequenceDictionary to adhere to character set restrictions in SAM/BAM RNAME spec. see: samtools/hts-specs#333 Roll back test input now that we are doing the sanitization. As of this commit, sanitization is only performed on fasta files destined for CreateSequenceDictionary * switch to lz4-bin from conda-forge change lz4 dependency from lz4-bin from bioconda to lz4-c from conda-forge, v131->v1.9.1 * picard 2.20.3 -> 2.20.5 * krona 2.7 -> 2.7.1 * override channels for tool install, each time * switch to picard-slim package switch to picard-slim package (sans 'r'); specify USE_JDK_DEFLATER=true and USE_JDK_INFLATER=true until bug in Intel deflator is fixed to prevent sporadic crashes * update temp suffix for sanitized fastas * revert to corrected test input revert to corrected test input

Disallow \ , "`' (){} punctuation characters in VCF contig IDs. The characters []<> were already disallowed in VCF; this also relaxes the prohibition of * to merely disallowing initial *. Statistics gathered from various reference sequence archives suggest that the characters restricted appear vanishingly infrequently in SAM reference sequence names in existing files in the wild. To the extent that all contig IDs in VCF files come from corresponding SAM/BAM files, this means there is little concern about making the same restrictions in VCF contig IDs. Fixes samtools#124 and fixes samtools#167 for VCF; their SAM aspects were previously fixed by PR samtools#333.

…llow colons) (#379) * Allow colons in VCF Contig IDs: breakend notation is unambiguous Breakend notation always includes a ":pos" part, so breakends are unambiguous even if the "chr" in "chr:pos" also itself contains colons. As this is a relaxation of the previous rules, there is no concern about altering all three 4.1/4.2/4.3 specs. Fixes the VCF/colon aspects of #124. Fixes #258. Closes #291. * Restrict allowed VCF Contig ID chars to those allowed in SAM RNAMEs Disallow \ , "`' (){} punctuation characters in VCF contig IDs. The characters []<> were already disallowed in VCF; this also relaxes the prohibition of * to merely disallowing initial *. Statistics gathered from various reference sequence archives suggest that the characters restricted appear vanishingly infrequently in SAM reference sequence names in existing files in the wild. To the extent that all contig IDs in VCF files come from corresponding SAM/BAM files, this means there is little concern about making the same restrictions in VCF contig IDs. Fixes #124 and fixes #167 for VCF; their SAM aspects were previously fixed by PR #333.

jmarshall added the sam label Aug 23, 2018

jmarshall mentioned this pull request Aug 23, 2018

New OA tag for storing Orignal Alignment information when modifying records #193

Closed

jmarshall force-pushed the tighten-rname branch from d131782 to 16cff42 Compare September 5, 2018 17:26

jmarshall mentioned this pull request Sep 5, 2018

Add support for SQ-AN in SAMSequenceDictionary samtools/htsjdk#956

Closed

5 tasks

yfarjoun pushed a commit to samtools/htsjdk that referenced this pull request Sep 17, 2018

- implementing the spec change in samtools/hts-specs#333

34b13e0

jmarshall force-pushed the tighten-rname branch from 16cff42 to f306c75 Compare September 19, 2018 11:41

jmarshall force-pushed the tighten-rname branch from f306c75 to 8c27bc4 Compare September 19, 2018 11:44

jmarshall changed the title ~~[DRAFT] Disallow commas and other punctuation in RNAME etc~~ Disallow commas and other punctuation in RNAME etc Sep 19, 2018

jmarshall force-pushed the tighten-rname branch from 8c27bc4 to 7505297 Compare September 20, 2018 08:48

yfarjoun pushed a commit to samtools/htsjdk that referenced this pull request Dec 5, 2018

- implementing the spec change in samtools/hts-specs#333

f92253b

yfarjoun mentioned this pull request Dec 5, 2018

- implementing the spec change in samtools/htsjdk#1238

Merged

jkbonfield approved these changes Dec 12, 2018

View reviewed changes

yfarjoun approved these changes Jan 10, 2019

View reviewed changes

jmarshall force-pushed the tighten-rname branch from e38e9b0 to f36d071 Compare January 11, 2019 13:13

jmarshall force-pushed the tighten-rname branch from f36d071 to 7fd686b Compare January 15, 2019 17:23

jmarshall merged commit 7fd686b into samtools:master Jan 16, 2019

jmarshall temporarily deployed to github-pages January 16, 2019 17:59 Inactive

jmarshall deleted the tighten-rname branch January 16, 2019 17:59

jmarshall mentioned this pull request Feb 5, 2019

Restrict allowed VCF Contig ID chars the same way as SAM RNAME (and allow colons) #379

Merged

jmarshall mentioned this pull request Feb 22, 2019

Ensembl fasta files no long usable as references samtools/htsjdk#1295

Open

tomkinsc mentioned this pull request Jul 11, 2019

update picard 2.18.11 -> 2.20.3 broadinstitute/viral-ngs#977

Merged

jmarshall mentioned this pull request Feb 3, 2020

Harmonise identifier (e.g. RNAME/Contig, Sample) rules across formats and protocols ga4gh/TASC#5

Open

rwinand mentioned this pull request Sep 3, 2020

Parentheses in RNAME #526

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Disallow commas and other punctuation in RNAME etc #333

Disallow commas and other punctuation in RNAME etc #333

jmarshall commented Aug 23, 2018 •

edited

Loading

yfarjoun commented Sep 17, 2018

jmarshall commented Sep 17, 2018

jmarshall commented Sep 19, 2018 •

edited

Loading

jmarshall commented Sep 19, 2018 •

edited

Loading

yfarjoun commented Sep 20, 2018 •

edited

Loading

jkbonfield commented Sep 20, 2018 •

edited

Loading

jkbonfield commented Sep 20, 2018

yfarjoun commented Sep 20, 2018

jkbonfield commented Oct 15, 2018

jmarshall commented Oct 15, 2018

yfarjoun commented Dec 5, 2018

jkbonfield commented Dec 6, 2018 •

edited

Loading

yfarjoun commented Dec 6, 2018

jmarshall commented Dec 6, 2018 •

edited

Loading

jkbonfield commented Dec 6, 2018

jmarshall commented Dec 6, 2018 •

edited

Loading

jkbonfield commented Dec 6, 2018

jmarshall commented Dec 19, 2018

jmarshall commented Jan 10, 2019

jkbonfield commented Jan 10, 2019

jmarshall commented Jan 11, 2019

jkbonfield commented Jan 11, 2019

jmarshall commented Jan 11, 2019

Disallow commas and other punctuation in RNAME etc #333

Disallow commas and other punctuation in RNAME etc #333

Conversation

jmarshall commented Aug 23, 2018 • edited Loading

yfarjoun commented Sep 17, 2018

jmarshall commented Sep 17, 2018

jmarshall commented Sep 19, 2018 • edited Loading

jmarshall commented Sep 19, 2018 • edited Loading

yfarjoun commented Sep 20, 2018 • edited Loading

jkbonfield commented Sep 20, 2018 • edited Loading

jkbonfield commented Sep 20, 2018

yfarjoun commented Sep 20, 2018

jkbonfield commented Oct 15, 2018

jmarshall commented Oct 15, 2018

yfarjoun commented Dec 5, 2018

jkbonfield commented Dec 6, 2018 • edited Loading

yfarjoun commented Dec 6, 2018

jmarshall commented Dec 6, 2018 • edited Loading

jkbonfield commented Dec 6, 2018

jmarshall commented Dec 6, 2018 • edited Loading

jkbonfield commented Dec 6, 2018

jmarshall commented Dec 19, 2018

jmarshall commented Jan 10, 2019

jkbonfield commented Jan 10, 2019

jmarshall commented Jan 11, 2019

jkbonfield commented Jan 11, 2019

jmarshall commented Jan 11, 2019

jmarshall commented Aug 23, 2018 •

edited

Loading

jmarshall commented Sep 19, 2018 •

edited

Loading

jmarshall commented Sep 19, 2018 •

edited

Loading

yfarjoun commented Sep 20, 2018 •

edited

Loading

jkbonfield commented Sep 20, 2018 •

edited

Loading

jkbonfield commented Dec 6, 2018 •

edited

Loading

jmarshall commented Dec 6, 2018 •

edited

Loading

jmarshall commented Dec 6, 2018 •

edited

Loading