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

Marcos Sanz/Denic <> Tue, 29 August 2006 11:01 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GI1LP-00046y-8u; Tue, 29 Aug 2006 07:01:23 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GI1LO-00046q-Ax for; Tue, 29 Aug 2006 07:01:22 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1GI0EZ-0007YH-Rj for; Tue, 29 Aug 2006 05:50:15 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1GI0BC-00040b-UF for; Tue, 29 Aug 2006 05:46:50 -0400
Received: from ([]) by with esmtp id 1GI0BB-0005lC-Pm; Tue, 29 Aug 2006 11:46:45 +0200
In-Reply-To: <>
To: Andrew Newton <>
Subject: Re: [Crisp] Last Minute Last Call Comments on lwz-06
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
From: Marcos Sanz/Denic <>
Message-ID: <>
Date: Tue, 29 Aug 2006 11:46:39 +0200
X-MIMETrack: Serialize by Router on notes/Denic at 29.08.2006 11:46:45, Serialize complete at 29.08.2006 11:46:45
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Cross Registry Information Service Protocol <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>


> > There were some comments during Last Call on the draft in the general 
> > 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 
> this list, that might be too much.

Well, it's not too much for me. But I don't know who decides where the 
threshold for addition for notes is.

> > *Section 3.1.2, 1st bullet: How realistic is that the transaction ID 
> > 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.

Fine by me. It was more like a sanity check, to see if I was overseeing 

> > *Section 3.1.5: "...and use the <versions> element as the root 
> > That's true except for "vi" queries.
> Hmmm... that section could be better explained with regard to this 
> On a request, types of 'vi' do not contain anything, but on a response 
> 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 
> > that this shouldn't be dealt with at the transport level (neither XPC 
> > BEEP do that for instance!) and would drop this reason, but I don't 
> > 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).


As we seemed to agree in
the BEEP reply codes 500/501 refer to the XML of the transport protocol 
itself, not to the XML of the payload.

And the only usage for 'vi' type in XPC that I have been able to find is

   Clients MAY send a block with this type of chunk to a server.  These
   chunks SHOULD be zero length and servers MUST ignore any data in
   them.  When a server receives a chunk of this type, it MUST respond
   with a chunk of this type.  This interchange allows a client to query
   the version information of a server.

which doesn't mean that 'vi' must be sent by the server when the 
IRIS-based XML payload does not match a version the server supports.


Crisp mailing list