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
- [Crisp] I-D ACTION:draft-ietf-crisp-iris-xpc-03.t… Internet-Drafts
- Re: [Crisp] I-D ACTION:draft-ietf-crisp-iris-xpc-… Robert Martin-Legene
- Re: [Crisp] I-D ACTION:draft-ietf-crisp-iris-xpc-… Robert Martin-Legene
- Re: [Crisp] I-D ACTION:draft-ietf-crisp-iris-xpc-… Andrew Newton
- Re: [Crisp] I-D ACTION:draft-ietf-crisp-iris-xpc-… Robert Martin-Legene
- Re: [Crisp] I-D ACTION:draft-ietf-crisp-iris-xpc-… Andrew Newton