From OpenWetWare
Revision as of 03:17, 3 April 2009 by Raik (talk | contribs) (comment arguing against this replacement)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Raik 03 April 2009

RFC 20 is, in fact, NOT a relaxation of RFC 10 but rather breaks compatibility with both RFC 10 and all derived formats. Let me explain: Replacing PstI by SbfI-HF looks like a good idea because it reduces the number of cases where one has to mutate or synthesize the part DNA. SbfI-HF is chosen so that most parts adhering to RFC 10 would still be compatible with the classic PstI / EcoRI assembly. BUT, this is where the trouble starts:

(1) Some RFC 20 parts will not be compatible with the classic assembly because they contain PstI sites. That means, users who want to assemble old (RFC 10) and new (RFC 20) parts will have to adapt their protocol and enzymes on a case-by-case basis. They cannot completely switch to the SbfI-HF because it is not working with RFC 10 (or any of the derived formats). But they cannot just use the old assembly, either.

(2) Once PstI containing Biobricks are mixed into an assembly, the resulting Biobrick is incompatible with further (RFC 10) standard assemblies. To be more exact, it can only be extended further in one direction. But it -- or anything derived from it -- cannot any longer be used as suffix part in standard assembly. Now that's a real problem. Remember, the whole point was to be able to mix RFC 10 and RFC 20 parts. In reality, there is a real danger to get stuck -- sooner or later you will end up with a Biobrick that has the classic RFC 10 prefix and suffix but nevertheless contains PstI sites. That's it, end of story.

(3) Some protocols rely on the exact RFC 10 prefix or suffix sequence which can serve, for instance, as standard priming site for PCR reactions. For example, several labs linearize the destination vector by PCR rather than by digestion: Prbbbb:vector_pcr. Again, it would disrupt the flow of these assemblies if one would need to check and pick 'correct' primers for each assembly reaction separately.

(4) RFC 20 proposes to replace one of the two 'outer' restriction enzymes. That means we need new construction vectors for this assembly. The most commonly used set of pSB1AC/K/T3 plasmids for 3A assembly will not work.

(5) RFC 20 does obviously not solve the protein fusion problem. There are two major formats out there that allow the assembly of fusion proteins: Silver/BioFusion (RFC 23) and Freiburg/Fusion (RFC 25 underway). Both are modifications of RFC 10. Both use PstI and the old set of enzymes. Both formats can mostly (RFC 23) or always (RFC 25) be combined with classic (RFC 10) Biobricks. The proposed RFC 20 Biobricks will again, in some cases, not work together with these formats. Where they do work, mixed assembly can potentially create hybrid Biobricks with a suffix that mixes RFC 25 and RFC 20, for example.

I think, in the current situation, the considerable downstream costs and complications of adopting RFC 20 would outweigh the added convenience. Right now, we should try to avoid a further degradation of the classic standard. RFC 20 would only be a temporary solution anyway, until we have settled on a next generation format that also solves the protein fusion issue. On the other hand, replacing PstI by SbfI-HF could indeed be a very useful idea for this future generation assembly standard.