On 19-Mar-06, at 10:11 PM, Granqvist, Hans wrote:
Just a few comments/questions while reading the latest draft,
which by the way is *not* in text but html format at
http://dixs.org/index.php/Draft-merrells-dix-01.txt (grrr)
Sorry, that revision was too late to be published through
ietf.org. You'll find 00 here:
http://www.ietf.org/internet-drafts/draft-merrells-dix-00.txt
Thanks for the rest of your comments. I'll reply and reflect
them into an updated draft after the DIX BOF tomorrow.
John
---
In 5.3. Capability URI :
If capability is equal to '1*ALPHA' then it's impossible to say
whether a capability is dix or non-dix since a capability
could contain a dot ('.'). (Perhaps 'ALPHA' is not properly
defined -- the character set of ALPHA used elsewhere contains
the dot.)
---
In 5.8. Capability Revisions
"From that point in the document onwards is what is included in
'dix://sxip.net/simple#34'."
I had to read this sentence a few times to understand. Can it
be reworded?
---
In 5.9.1.1. dix:/core#1
"Core DIX protocol capabilities. The simple usage profile. Our
assumptions are: low security, low risk identity transaction,
data is
moving over HTTP(S), low risk from replay attack."
What do these assumptions mean, for example "low security"? And is it
possible to assume which transport is used -- does it even make sense
if DIX is defined to be transport agnostic?
---
5.10.1.1. Membersite Cookie (Dumb Client)
"Once a user has visited a Membersite and identified the name of
their
Homesite that Membersite can cookie the user with their choice of
Homesite, so that it can be filled in automatically for them in the
future."
The verb "to cookie someone" seems a bit over the top. :)
---
5.10.1.2. User Prompt
"Homsite Path"
Just a spelling mistake.
"The attributes of the FORM tag are:
o CLASS attribute must contain 'sxip', which denotes to a smart
client that the form was generated by a DIX aware Membersite."
There is a 'sxip' reference requirement here that I don't understand.
---
5.10.1.4. Homesite Inspection
"The Membersite must now determine the Endpoint URL and the
Capabilities of the User's Homesite. The Membersite uses the
Homesite
Tag Inspection Algorithm to discover the Homesite Tag."
This algorithm is undefined by name in the document.
"The Homesite Tag is used to specify the Endpoint URL and
Capabilities
of a Homesite. The HTML LINK tag is used for this. The LINK tag
is .
. ."
All of a sudden there is a dependency on HTML here, which really
should
be stated up-front in the document, I think.
---
5.10.2.2. Digest Generation
"th'dix:/signature'"
Another spelling mistake (I hope! ;)
"Signature = T ( S + Digest )"
I am sure this is intentionally simplified in the document, but
since this is technically not a correct HMAC, it should be
reworded. (The concat is different, see RFC2104)
---
5.10.2.7. Message Canonicalization
'. apply the following URI encodings to keys and values:
. all "=" are encoded to "%3D", note the uppercase 'D'
. all "&" are encoded to "%26"
. all "%" are encoded to "%25"'
What about other characters that are normally encoded? Are they
intentionally excluded?
'. byte-order sort all joined pairs
. join all joined pairs into one string with "&" as a separator'
I am confused what this means. An example would help!
That's it so far . . .
Hans
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
