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

Andy,

> > 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.

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 
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.

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

> > *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.

Exactly.

> > *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).

Really?

As we seemed to agree in
http://www1.ietf.org/mail-archive/web/crisp/current/msg00413.html
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.

Best
Marcos

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