Re: [Crisp] I-D ACTION:draft-ietf-crisp-iris-xpc-03.txt

On Mar 20, 2006, at 1:41 PM, Robert Martin-Legene wrote:

> Comments and questions regarding draft-ietf-crisp-iris-xpc-03:
>
> The connection response block (CRB) contains an <?xml?> header. Isn't
> an XML-document mandated to exactly one root level element? I see
> several root level elements when the individual blocks are put
> together. Maybe each chunk type in each block considered an individual
> XML document? Eg. a clients sends two requests in a block, first being
> a 'vi' (version info) request and the next being 'ad' (application
> data). But each have their own root level element.
>
> In the examples the server starts a block with <?xml?> but the client
> doesn't. Isn't it mandatory in XML? Also, I don't see how the client
> would otherwise specify whether it uses UTF-8 or UTF-16? I am an XML
> newbie.

The XML declaration is optional.  When a declaration is not present,  
the BOM determines UTF-8 or UTF-16.

> About chunk types, when is the server supposed or expected to close
> the connection for chunks of the type 010 (size info), 011 (other
> info) and 110 (auth fail)? Of course the server can just clear the
> KO-flag as it sees fit and close the connection, but is a
> recommendation needed?

For size info, I see your point.  I don't think it would hurt  
anything to suggest that servers ought to shut down the connection  
because it is unlikely that a client would recover from this.

> Nothing written about what happens if the client sends a size-info or
> other-info chunk. What is expected?

That depends on the type of client.  Typically the error would be  
logged or displayed to the user.

> In the SASL discussion you limit the SASL information to not span
> chunks. I.e. be maximum 255 octets. The (expired) draft that I read
> (draft-ietf-sasl-plain-08) says that this limit is too little (with 2
> or 3 fields of 255 octets each). Of course we can not care since it's
> not an RFC (what happened to that draft anyway?), but would it be wise
> to consider this in the future?

The mechanism name is restricted to 255 characters.  The SASL data  
itself can take up the rest of the chunk, so 65536 - 3 - length of  
mechanism name.  That should be plenty of room.

> In the references, [2] refers to rfc 3892 when it should state 3982.

Ooops!

> Final spelling correction:
>
> Section 6 still mentions "seventh bit", but a second later changes to
> call it "bit 0"

My uncaffeinated  review indicates that it should read "first bit".   
This is obviously a hold over from the iteration of the draft that  
had the bit ordering reversed.

-andy

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