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

From: "Robert Martin-Legene" <[email-masked]>
Date: Mon, 20 Mar 2006 19:41:38 +0100

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.

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? Not sure, because how would one recover from
this? Especially with the size info, it doesn't make sense to keep
reading from the client if he has exceeded his bounds, but then again
the draft says to not expect the client to read a block until he has
sent his entire block. So shutting down your end of the socket would
normally make his client mess up. Maybe maybe maybe a suggestion to
client application programmers could suggest to check if there are
inbound data even if the socket seems to have been closed while
writing. In xpc2 you say?

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

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?

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

Final spelling correction:

Section 6 still mentions "seventh bit", but a second later changes to
call it "bit 0"

_______________________________________________
Crisp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/crisp

---

From: "Robert Martin-Legene" <[email-masked]>
Date: Mon, 20 Mar 2006 22:52:09 +0100

I'm sorry if the language seemed a bit weird. It started out as notes
for myself and just evolved and got their own life and I forgot to
leave it aside for a few hours before proof reading it.

Anyway, my previous mail still has some points that aren't clear. If
someone knows or has an opinion on either of my questions I am happy
to hear about it.

---

From: Andrew Newton <[email-masked]>
Date: Tue, 21 Mar 2006 08:24:43 -0500

> would otherwise specify whether it uses UTF-8 or UTF-16? I am an XML

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

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

> other-info chunk. What is expected?

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

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

> Section 6 still mentions "seventh bit", but a second later changes to

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

---

From: "Robert Martin-Legene" <[email-masked]>
Date: Wed, 22 Mar 2006 23:05:55 +0100

Dear everyone.

As was just mentioned in the WG meeting in Dallas, two days ago I
found something odd in the XPC draft. It seems there was no seperate
tcp port registration for XPCS (XPC via TLS). Andy thought it was in
there, but it somehow has not made it into the draft. So the document
needs to be revised again.

Then there's also time to put in a tiny section about that the server
SHOULD (?) close the connection if it receives chunk  type 010 (size
info), 011 (other info) or 110 (auth fail) from the client. For an
implementor, it's nice to have an accurate recipe.

BTW, is it a problem to mention SASL PLAIN when RFC2595 is for "IMAP,
POP3 and ACAP"?  Section 6 paragraph 2 of the RFC does actually say
"This defines the "PLAIN" SASL mechanism for use with ACAP and other
protocols with no clear-text login command.". So maybe it's ok? Btw,
it's not in the references either, so maybe I'm just barking up the
wrong tree.

I don't think I have anything else I can put my finger on.

Thank you for a super fast meeting.

-- Robert Martin-Legene, .dk

---

From: Andrew Newton <[email-masked]>
Date: Wed, 22 Mar 2006 18:19:54 -0500

> it's not in the references either, so maybe I'm just barking up the

At the time this draft was written, the new SASL PLAIN draft was not  
done and the normative reference to SASL PLAIN is 2595.  Other  
protocols have done this too.  Since I have to respin this draft,  
I'll check to see if the reference has changed to the new document  
that pulls SASL PLAIN out of IMAP.

-andy