<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=US-ASCII" http-equiv="Content-Type">

  <title></title>

</head>

<body bgcolor="#ffffff" text="#000000">

Brad Fitzpatrick wrote:

<blockquote cite="midPine.LNX.4.58.0506051532070.3121@danga.com"

 type="cite">

  <pre wrap="">On Sun, 5 Jun 2005, Paul Crowley wrote:

  </pre>

  <blockquote type="cite">

    <pre wrap="">OK.  What format do we use for the replies from servers to consumers

about server secrets?  We should probably use the same format as that

for the signatures.  I was thinking x-www-form-urlencoded there, but as

you say that might be hard for consumers to parse when it's part of the

reply rather than part of the request.

    </pre>

  </blockquote>

  <pre wrap=""><!---->

You'll hear every debate.  Some people will say text/line-based protocol

is easiest.  Some will want x-www-form-urlencoded encoding, and some will

actually prefer XML, as it's built into their language/envifornemnt.

I'd say in the interest of consistency we go with x-www-form-urlencoded.

It's not that hard to parse, and it's usually possible to coerce a web

framework's API to do most the heavy lifting of decoding it anyway.

  </pre>

</blockquote>

I must really be missing something!<br>

*Where* is the need to parse back the signed string?<br>

I understand that it's content may be subject to variations and

therefore must be customisable and readily enumerable.<br>

But isn't every field in it in already available on each side, customer

and server as well, and thus the whole string can be rebuilt anyway

before the signing or verification?<br>

<br>

JLD<br>

<br>

<br>

<br>

<br>

<br>

<br>

<br>

<br>

<br>

</body>

</html>