Re: [Crisp] Last Minute Last Call Comments on lwz-06

Andrew Newton <andy@hxr.us> Mon, 28 August 2006 17:52 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHlI6-00083V-GK; Mon, 28 Aug 2006 13:52:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHlI5-0007z4-B0; Mon, 28 Aug 2006 13:52:53 -0400
Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHlI4-0005M6-46; Mon, 28 Aug 2006 13:52:53 -0400
Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Mon, 28 Aug 2006 13:52:49 -0400 id 01588037.44F32D71.000038D9
Message-ID: <44F32D6E.7060806@hxr.us>
Date: Mon, 28 Aug 2006 13:52:46 -0400
From: Andrew Newton <andy@hxr.us>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: "Marcos Sanz/Denic" <sanz@denic.de>
Subject: Re: [Crisp] Last Minute Last Call Comments on lwz-06
References: <OF331B8A93.4BF92D8E-ONC12571D8.004FD330-C12571D8.005EEBEC@notes.denic.de>
In-Reply-To: <OF331B8A93.4BF92D8E-ONC12571D8.004FD330-C12571D8.005EEBEC@notes.denic.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: crisp@ietf.org, iesg@ietf.org
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

Marcos Sanz/Denic wrote:
> There were some comments during Last Call on the draft in the general list 
> and my guess is that maybe Andy is going to do a new version with some 
> additional text in the security/MTU/congestion/retry issues. 

I was originally thinking about RFC Editor notes, but with the addition of 
this list, that might be too much.

> *Section 3.1.2, 1st bullet: How realistic is that the transaction ID in 
> the request could not be read due to truncation? The transaction ID 
> occupies the bits in the positions 73rd to 88th!

Highly unlikely, but odds things happen and this is a well described 
explanation of what to do when this particular odd thing happens.

> *Section 3.1.3: "The bits of the payload header are ordered..." I think 
> this sentence is redundant, because terminology has been already 
> introduced extensively in section 2.

Yeah, but we kept discussing this on the list over and over again that I 
felt it was necessary to drive the point home.

> *Section 3.1.5: "...and use the <versions> element as the root element." 
> That's true except for "vi" queries.

Hmmm... that section could be better explained with regard to this matter. 
On a request, types of 'vi' do not contain anything, but on a response they 
contain the <versions> xml.

> *Section 3.1.5: One cause for sending 'vi' type is "The IRIS-based XML 
> payload does not match a version the server supports." My gut feeling is 
> that this shouldn't be dealt with at the transport level (neither XPC nor 
> BEEP do that for instance!) and would drop this reason, but I don't have 
> strong feelings about this.

Actually, I believe both do (though the BEEP error code may be a little 
difficult to guess what it should be).


Thanks for the comments.

-andy


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