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

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