Re: protocol draft "little" issues

Magnus Nystrom <[email protected]> Fri, 15 Feb 2002 16:29:35 +0100 (W. Europe Standard Time)
Newsgroups gmane.ietf.sacred
Message-ID <Pine.WNT.4.43.0202151624080.1452-100000@mnystrom-lap>
Hi Stephen,

A few comments (were I have a different view).

On Thu, 14 Feb 2002, Stephen Farrell wrote:

> Folks,
>
> The protocol draft contains the list of "minor" open issues
> below, that I'd like to get sorted.
>
> If you have a suggestion/problem/wanna-chat about any of the
> suggested resolutions can you start a thread on the list over
> the next week or so? (Expressing your agreement is also fine,
> since silence!=concensus:-)
>
>    - If a server only supports up/down-load, then is SRP alone
>      sufficient or MUST the server also support cTLS? (The latter
>      according to the current text.)
>
>           [cTLS is only a MUST for those that implement account
>           management stuff.]

In a scenario where a client wants to download a second set of
credentials, SRP would not be necessary. I'd say keep the current text.
Not too much to ask of a server to support both.

>    - Meaning of empty string for credential selector?
>
>           ["" means "all credentials", same as if the selector
>           field is omitted entirely]
>
>    - Does section 2.4 need changes?
>
>           [this will be deleted as per list discussion, some
>           "anti-DoS" text will be added to sec cons.]
>
>    - Should we apply for a port number? (probably)
>
>           [no.]

Yes. This is a new protocol.

>    - Should we define a URI scheme? (probably not)
>
>           [no.]
>
>    - Should the DTD or schema be normative? I'd usually go for the
>      schema, but in this case the DTD seems much simpler.
>
>           [since its much simpler let's make the DTD normative but
>           keep the schema correct & up to date]

The schema is my preference. I would also like it to be designed in a
"SAML-manner" or "XKMS-manner", i.e. basic building blocks "RequestType",
"ResponseType", that are extended for various types of requests and
responses. More general.

-- Magnus