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

Andrew Newton <> Mon, 28 August 2006 17:52 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GHlI6-00083V-GK; Mon, 28 Aug 2006 13:52:54 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GHlI5-0007z4-B0; Mon, 28 Aug 2006 13:52:53 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1GHlI4-0005M6-46; Mon, 28 Aug 2006 13:52:53 -0400
Received: from [] ([::ffff:]) (AUTH: LOGIN anewton) by with esmtp; Mon, 28 Aug 2006 13:52:49 -0400 id 01588037.44F32D71.000038D9
Message-ID: <>
Date: Mon, 28 Aug 2006 13:52:46 -0400
From: Andrew Newton <>
User-Agent: Thunderbird (Windows/20060719)
MIME-Version: 1.0
To: Marcos Sanz/Denic <>
Subject: Re: [Crisp] Last Minute Last Call Comments on lwz-06
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Cross Registry Information Service Protocol <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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.


Crisp mailing list