BBF RFC 20

The RFC is at http://hdl.handle.net/1721.1/44962

Comments are on this page

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.

Austin Che 11:37, 3 April 2009 (EDT)

Thanks for your comments Raik. I'll respond to your different points but I'll first summarize my points.

I believe the adoption of RFC 20 is a good idea because it reduces experimental work and gives users more freedom in part design. Mutagenesis to remove restriction sites is one of the more time consuming steps of making a part. Adding two bases to make a SbfI site instead of a PstI when making a part is no extra work. Making new vectors is a one-time cost and there are less than 10 commonly used plasmids.

  On the other hand, there are still 3 other restriction enzymes to worry about 
  (or 5 in the case of the Fusion format). So the benefit is not that big. 
  Besides, right now, we don't have those construction vectors available, have we?
  *Raik 07:58, 4 April 2009 (EDT)

• Austin Che 11:54, 4 April 2009 (EDT): I'm not sure how having more restriction enzymes reduces the benefit. This isn't a tradeoff between not having to do any mutagenesis and having to do more than one mutagenesis, but rather how many changes you have to make. If you have a PstI site in your promoter that you just can't mutate, you sure don't care if your assembly standard contains 3 restriction enzymes or 5 as long as it doesn't use PstI. Again, making construction vectors is really easy. Many people, including yourself it seems, are making construction vectors by PCR. This would simply be using a different set of primers.

There are five types of assemblies:

1. RFC 10 part with RFC 10 part -> RFC 10 part
2. RFC 10 part with RFC 20 part -> RFC 20 part
3. RFC 20 part with RFC 10 part -> RFC 10 part *
4. RFC 20 part with RFC 20 part -> RFC 20 part
5. RFC 10 part -> RFC 20 part (explicit move)

You bring up a good point about problems with assembly type 3 where the RFC 20 part contains PstI sites because it produces a RFC 10 part.

  Unfortunately, if you mix several RFC 10 parts with several RFC 20 parts, then you are almost 
  certainly going to encounter situation 3 somewhere along the chain of assembly reactions. So
  the problem is quite likely to occur during the assembly of larger constructs.
  *Raik 07:58, 4 April 2009 (EDT)

• Austin Che 14:33, 4 April 2009 (EDT): You're ignoring the transition plans I list below. If you want to be conservative and never think about your assemblies, you can follow the no-brainer transition strategy and not do anything different from what you are currently doing. With this approach, you will NEVER encounter situation 3. But in the process, you will be helping out everyone else who does want to standardize on SbfI.

There are different transition plans depending on what an individual user wants. One of the advantages is that different users can choose different strategies for their sets of parts. The common elements of all the transition strategies is to always use a RFC 20 destination vector and always cut the prefix part with EcoRI/SpeI. The differences are whether to allow PstI sites in new RFC 20 parts, whether to proactively move parts into RFC 20 format, and whether to use different enzymes to digest the suffix part.

The no-brainer transition strategy: Make no PstI containing RFC 20 parts and only use RFC 10 assembly with RFC 20 vectors. You can continue to make parts that do not contain any PstI sites (i.e. compatible with RFC 10) but that contain a RFC 20 suffix (SbfI). This is really no extra work for the part maker as all you're doing is adding an extra two bases from what you would be doing anyway. For people who want to continue to use a consistent enzyme, they can continue to use PstI, but assemble into a RFC 20 destination vector. If people followed this procedure, which is identical to what they are currently doing, except that a new destination vector is being used, then more and more parts will become RFC 20 parts, with no extra work. Note that at some point, you will have to jump to a different strategy. Otherwise, you get no benefit from using RFC 20. But this is the recommended initial strategy to build up the collection of RFC 20 parts.

The upgrade as needed strategy: Whenever a RFC 10 part is needed for an assembly or when someone decides that a part is highly used, the part is moved into RFC 20 format by digesting it with EcoRI/SpeI and moving it to a RFC 20 plasmid. This is a relatively simple operation and can be done in parallel with other cloning operations. For example, anytime a RFC 10 part is used as a prefix part in an assembly (i.e. it's cut with EcoRI/SpeI), we do two ligations and transformations: one ligation with the desired suffix part and one ligation into a RFC 20 plasmid (or equivalently ligation with an XbaI/SbfI cut "empty part"). This requires minimal extra work and only moves parts as needed. Highly used parts then become in RFC 20 form.

The I need some PstI sites strategy: Make PstI containing RFC 20 parts. For the users who just really want to leave a PstI site in either because it's too difficult to mutate or because it's in a region that is dangerous to mutate, they can begin to push the boundaries between the two RFCs. These RFC 20 parts must be digested with SbfI. Assembly type 3 may become a problem but can be solved by converting either the input RFC 10 part or the output RFC 10 to a RFC 20 part.

The mixed approach: Cut all RFC 20 parts with SbfI and all RFC 10 parts with PstI. Clearly, this requires an extra bit of information to be maintained so that the correct enzyme can be chosen. At this point, I would assume that the majority of parts being used are in RFC 20 form.

These transition strategies can be mixed at will and the key is that all roads lead to the majority of parts becoming RFC 20 parts, at which point you reach

The end state: Most parts are in RFC 20 form. There are some remaining parts in RFC 10 but these have not been used much or deemed worthwhile to be made into RFC 20. Assemblies use SbfI instead of PstI and new parts are designed that can contain PstI sites.

My response to your points:

(1) It is unclear what you mean by RFC 20 parts are not compatible with RFC 10 parts. It is always possible to assemble a RFC 20 part with a RFC 10 part even if the RFC 20 part contains a PstI site. You are correct that in the transition period, you may have sets of RFC 10 parts and sets of RFC 20 parts. Thus, you may have to use a different enzyme to cut the different parts. But this is the choice of the user and the choice of the transition strategy.

  What I meant was that RFC 20 parts are not compatible with the RFC 10 assembly process.
  You cannot any longer rely on RFC 20 parts to behave like RFC 10 parts during a chain of
  assembly reactions. RFC 20 parts can potentially poison your assembly with PstI sites,
  their suffix may be rejected by your automatic sequence check program, you have to verify
  the nature of your construction vectors, etc. pp. 
  *Raik 07:58, 4 April 2009 (EDT)

(2) You can never get stuck. You are correct that if you have a PstI containing RFC 20 prefix part and you assemble it with a RFC 10 suffix part, then you will get a RFC 10 part containing a PstI site. First, the probability of this occurring can be made arbitrarily small depending on the transition plan. But suppose you do find yourself in this situation. Then you can simply move the part by cutting with EcoRI/SpeI and transferring it into a RFC 20 plasmid. You now have yourself a fully compliant RFC 20 part.

  OK, "stuck" is perhaps too strong a word. So there are workarounds to
  get out of this trap. But these workarounds require (1) that you are
  aware of the problem -- which is not completely trivial for iGem teams,
  (2) an extra cloning step and (3) may actually be required more than once
  during a chain of assembly reactions. Each extra cloning step throws you
  back by two or three extra days. Now that can be really annoying...
  *Raik 07:58, 4 April 2009 (EDT)

• Austin Che 14:33, 4 April 2009 (EDT): Like I said in the transition plan above, moving to RFC 20 form takes no extra time. It's an extra parallel step done with the cloning you're already doing and needs to only be done once for a part and only for certain parts. There absolutely no case where you need to do it more than once for a chain of assembly reactions.

(3) Ordering new primers is cheap. The whole point of RFC 20 is that you do not have to pick a destination vector. You ALWAYS use a RFC 20 destination vector. Note, that the primers that you link to would not need to be changed. They don't prime to the PstI site and thus they could be used as-is with a new destination vector.

  Point taken, in this particular case, the primers would still be valid.
  My concern was though that people may rely on the exact sequence for
  all kind of purposes. The outer part of the suffix is, so far, bullet-proof 
  equal for all RFC 10 derived formats (BBa, Silver/BioFusion, Freiburg/Fusion).
  Some labs are toying with PCR and recombination-based assembly protocols and
  will probably not appreciate to have even more variations to worry about.  
  *Raik 07:58, 4 April 2009 (EDT)

• Austin Che 14:33, 4 April 2009 (EDT): I think I know most of the PCR based assemblies approach out there and I still cannot understand how this could possibly affect things in any dramatic way. You can just consider the PstI part of the sequence as part of the plasmid. Are you suggesting that people should stop using different plasmids because they have different sequences? Because you might not be able to use the same primers to PCR up pSB1A3 and pSB4C5, everyone should just use a single plasmid.

(4) Yes, you need to make new vectors. That's a one-time, easy to do operation. Note that the pSBXX5 series are almost compatible already as they already have a G after the PstI site. Only a C needs to be inserted before the PstI site. Thus you can make an RFC 20 insert, cut all these plasmids with EcoRI/PstI, and ligate in the insert. If you're making destination backbone via PCR, you may not need to do any cloning other than order new primers.

  Yes, preparing the destination vector by PCR is an easy solution but, again, it may 
  not work for everybody. If you actually recommend people to switch right now, you 
  should also provide the tools to do so. So they, first of all, will need vectors and 
  exact protocols.
  *Raik 07:58, 4 April 2009 (EDT)

(5) I do not understand what you're saying here. Of course, RFC 20 is not intended to do anything about the protein fusion problem. All the RFC 10 derivatives for protein fusion should have no problem replacing the PstI with SbfI as it's the outermost restriction enzme. The outer enzymes are really "don't-cares" for RFC 10 and all its derivatives.

  That's exactly what I am scared about: Your proposal is not only adding yet another format
  to the current zoo but it actually will double the number of RFC 10 derived formats. If we 
  go ahead with the transition, we end up with RFC 10 BioBricks, RFC 20 BioBricks, RFC 23 (Silver)
  BioBricks, RFC 25 (Freiburg) BioBricks, plus hybrid RFC 23/20 BioBricks, hybrid RFC 25/20
  BioBricks and odd double-hybrids where RFC 20 or RFC */20 BioBricks have ended up in RFC 10
  construction vectors. And we end up with a generation of young Synthetic Biologists that are
  going to be pretty allergic to the mentioning of the word "standard" ;-).
  *Raik 07:58, 4 April 2009 (EDT)