Change diagrams to svg format.

A6.md

@@ -194,6 +194,8 @@ There are five possible types of server responses. The list below enumerates the
 
 ![State Diagram](A6_graphics/StateDiagram.png)
 
+[Link to SVG file](A6_graphics/StateDiagram.svg)
+
 ### Retry Internals
 
 #### Where Retries Occur
@@ -202,6 +204,8 @@ The retry policy will be implemented in-between the channel and the load balanci
 
 ![Where Retries Occur](A6_graphics/WhereRetriesOccur.png)
 
+[Link to SVG file](A6_graphics/WhereRetriesOccur.svg)
+
 #### When Retries are Valid
 
 In certain cases it is not valid to retry an RPC. These cases occur when the RPC has been *committed*, and thus it does not make sense to perform the retry.
@@ -239,6 +243,8 @@ RPC failures can occur in three distinct ways:
 
 ![Where RPCs Fail](A6_graphics/WhereRPCsFail.png)
 
+[Link to SVG file](A6_graphics/WhereRPCsFail.svg)
+
 The last case is handled by the configurable retry policy that is the main focus of this document. The first two cases are retried automatically by the gRPC client library, **regardless** of the retry configuration set by the service owner. We are able to do this because these request have not made it to the server application logic, and thus are always safe to retry.
 
 In the first case, in which the RPC never leaves the client, the client library will immediately retry the call once. If this immediate retry fails, then the failure will be treated just like the third bullet point. This means that it will be handled by the configured retry policy.