>>
>>I like the notion of essentially divorcing these two flows
>>from each other and basically not trying to directly map all
>>of the XML
>>in <Request> to a URL, which I think is a losing proposition.
>>
>>General comments:
>>
>>Since the query string is entirely defined by this profile, I
>>suggest saving space by reducing the size of the parameter names,
>>particularly dropping the SAML prefix in each case (no, it's
>>not much, but it's of zero-processing value).
>>
If at all possible, I would like to hang on to the SAML prefix. Think of it
as a crude form of XML's "fully qualified name"; it helps ensure that names
in the search part don't clash (and if they do, hey, why is someone else
using the SAML prefix?).
>>Doesn't base64 generally inflate the size of what it encodes?
>>I would think straight URL encoding of the data per usual practice
>>would make more sense in most cases.
I think it is a bit of a toss up in terms of which encoding would lead to
greater binary data inflation. I am less familiar with URL encoding but I
agree that it would do the job. I think one point in favor of URL encoding
is that the output of base64 results in a string that may further require
URL encoding (i.e., there is potential for further expansion even after
base64 encoding). So it would seem preferable to go directly for URL
encoding. I will make this change.
>>
>>Some of the length limitations seem a little tight,
>>particularly the RequestID. I would imagine I'm not the only
>>one who would have
>>implemented their IDs as UUIDs, which are more than 20 bytes.
>>I could special case this ID, but in general, I think we can relax
>>some of these limits and still end up in fairly good shape,
>>length-wise.
>>
How about hashing the UUID? Using SHA-1 you can always bring a value down to
20 bytes.
Admittedly, this is a somewhat nasty way to generate IDs. At the same time
requiring strings to have upper bounds is reasonably important here. What
would be an acceptable limit on RequestID?
>>I would prefer somewhat less hashing of URIs and things, and
>>more SHOULDs about length.
>>
Sounds reasonable. I will make a pass thru the document and see where these
suggestions might apply.
>>-- Scott
>>
