Re: [Crisp] I-D ACTION:draft-ietf-crisp-iris-xpc-03.txt

"Robert Martin-Legene" <rlegene@gmail.com> Mon, 20 March 2006 18:41 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLPK1-0003W6-ET; Mon, 20 Mar 2006 13:41:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLPK1-0003W1-2U for crisp@ietf.org; Mon, 20 Mar 2006 13:41:41 -0500
Received: from nproxy.gmail.com ([64.233.182.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLPJz-0005uZ-OW for crisp@ietf.org; Mon, 20 Mar 2006 13:41:41 -0500
Received: by nproxy.gmail.com with SMTP id n15so854128nfc for <crisp@ietf.org>; Mon, 20 Mar 2006 10:41:38 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jLu5jgNNqZbRNgc+v5kPT53ixA7F75nLztBcIQIlCRZbSPiNTeN/1RunInfuwvfMQHmqhHKkB4m9QUX/mj2EN7JGNFHLE2i5zWG+EV+AFb6gXrqrWLXhOCkdqKg07HBmliSVRiSvOj4aTqbIiHftf0xkSsS/+Rtn03qcqx/FyvY=
Received: by 10.48.157.4 with SMTP id f4mr1460692nfe; Mon, 20 Mar 2006 10:41:38 -0800 (PST)
Received: by 10.49.68.4 with HTTP; Mon, 20 Mar 2006 10:41:38 -0800 (PST)
Message-ID: <487354f10603201041k46b00b72x@mail.gmail.com>
Date: Mon, 20 Mar 2006 19:41:38 +0100
From: Robert Martin-Legene <rlegene@gmail.com>
To: crisp@ietf.org
Subject: Re: [Crisp] I-D ACTION:draft-ietf-crisp-iris-xpc-03.txt
In-Reply-To: <E1F7Ijq-0000Lb-92@newodin.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <E1F7Ijq-0000Lb-92@newodin.ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
X-BeenThere: crisp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Cross Registry Information Service Protocol <crisp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/crisp>, <mailto:crisp-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:crisp@ietf.org>
List-Help: <mailto:crisp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/crisp>, <mailto:crisp-request@ietf.org?subject=subscribe>
Errors-To: crisp-bounces@ietf.org

Comments and questions regarding draft-ietf-crisp-iris-xpc-03:

The connection response block (CRB) contains an <?xml?> header. Isn't
an XML-document mandated to exactly one root level element? I see
several root level elements when the individual blocks are put
together. Maybe each chunk type in each block considered an individual
XML document? Eg. a clients sends two requests in a block, first being
a 'vi' (version info) request and the next being 'ad' (application
data). But each have their own root level element.

In the examples the server starts a block with <?xml?> but the client
doesn't. Isn't it mandatory in XML? Also, I don't see how the client
would otherwise specify whether it uses UTF-8 or UTF-16? I am an XML
newbie.

About chunk types, when is the server supposed or expected to close
the connection for chunks of the type 010 (size info), 011 (other
info) and 110 (auth fail)? Of course the server can just clear the
KO-flag as it sees fit and close the connection, but is a
recommendation needed? Not sure, because how would one recover from
this? Especially with the size info, it doesn't make sense to keep
reading from the client if he has exceeded his bounds, but then again
the draft says to not expect the client to read a block until he has
sent his entire block. So shutting down your end of the socket would
normally make his client mess up. Maybe maybe maybe a suggestion to
client application programmers could suggest to check if there are
inbound data even if the socket seems to have been closed while
writing. In xpc2 you say?

Nothing written about what happens if the client sends a size-info or
other-info chunk. What is expected?

In the SASL discussion you limit the SASL information to not span
chunks. I.e. be maximum 255 octets. The (expired) draft that I read
(draft-ietf-sasl-plain-08) says that this limit is too little (with 2
or 3 fields of 255 octets each). Of course we can not care since it's
not an RFC (what happened to that draft anyway?), but would it be wise
to consider this in the future?

In the references, [2] refers to rfc 3892 when it should state 3982.

Final spelling correction:

Section 6 still mentions "seventh bit", but a second later changes to
call it "bit 0"

_______________________________________________
Crisp mailing list
Crisp@ietf.org
https://www1.ietf.org/mailman/listinfo/crisp