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

From: [email-masked]
Date: Mon, 02 May 2005 15:48:45 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF.

	Title		: XML Pipelining with Chunks for the Information Registry Information Service
	Author(s)	: A. Newton
	Filename	: draft-ietf-crisp-iris-xpc-00.txt
	Pages		: 32
	Date		: 2005-5-2
	
This document describes a simple TCP transport binding for the
   Internet Registry Information Service (IRIS).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-xpc-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-crisp-iris-xpc-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-crisp-iris-xpc-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Crisp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/crisp

---

From: Robert Martin-Legene <[email-masked]>
Date: Fri, 13 May 2005 13:31:34 +0200

Hello Andy, all.

I have finally converted my notes into electronic format.

The document surely evolved since I last saw it. It's nice to see. And
yes, I would still be able to handle the binary part from within perl
:)

First, I'd like to mention the trivial typos that I spotted.

Section 3:
	"wich" should be spelled "which".

Section 7:
	"chuck" is probably "chunk".

	"If this bit is never set to 0" is probably "If this bit is ever set to 0".

Section 8:
	5 minute timeout is probably 2? At least that's what you mention in
section 7.3. (Otherwise justify the difference?)

Appendix A:
	"hobbes.exmaple.com" should be "hobbes.example.com".

Now for more in-depth issues:

Section 3 mentions the authority and a reference to [1].. Not having
read [1] I just wonder if it's specified in [1] whether to match case
sensitively or not?

There are still some sections that I'd like to see shuffled around a
bit. Section 5 (Connection Response Block) would be nice to have
before Section 3 (Request Block), since it's the first block you
mention in the introduction.

In section 7 you suddenly start mentioning "the first bit" when
everywhere else you have been more specific and said "bit 7". I' think
it's important to keep the language consistent, as it's not completely
clear what is "first bit" (could be first bit on the wire or bit 0).

Then you have your flags and lots of them. While you write in Appendix
A that the flags "values of yes and no doesn't reflect binary values 0
and 1 but instead the associated positive or negative assertion of the
meaning of the flag". Well, that's a bit difficult to adapt to, and
for someone skimming the document without reading it thoroughly
in-depth, they would never see this. It does my head in because it's
not intuitively correct to expect a Connection Closing value of 0 to
means the server will close the connection. I would really like to see
that turned around.

Concerning the Keep Open and Connection Closing flags, what's the
reason for not merging these into a single flag? I know you have lots
of bits still unused, but the client will never say Connection
Closing, and the server will never say Keep Open.

I don't know anything about TLS so I can't comment on that. Maybe
someone else has a clue about that?

In the examples, each chunk of a block contains one complete XML
instance. Maybe it's a coincidence that the chunks doesn't have
fragmented XML instances? I thought an entity could span multiple
chunks (if not what would be the difference between blocks and
chunks)? The introduction says a chunk is a (possible) fragment of an
XML request/response.

-- Robert Martin-Legène, .DK

---

From: Andrew Newton <[email-masked]>
Date: Fri, 13 May 2005 10:49:01 -0400

Robert,

Thanks for the second review.  My comments are in-line:

> yes, I would still be able to handle the binary part from within perl

I look forward to seeing your implementation. :)

> 	"hobbes.exmaple.com" should be "hobbes.example.com".

Thanks.  I neglected sending the source xml2rfc through XMLMind 
because, like many XML authoring tools, it keeps reformatting the XML.

> read [1] I just wonder if it's specified in [1] whether to match case

Well, since that all maps back to the definition of an authority in a 
URI (as defined by RFC 2396), the answer is probably that it is not 
case sensitive.  I'll have to double check, but I'd doubt it would be 
otherwise since domain names are not case sensitive.  But I guess 
pointing what any matching semantics should be is a good thing.

> mention in the introduction.

Hmmm... A Connection Response Block (CBR) is simply just a type of 
Response Block (RSB), which is described in Section 4.  That's why I 
put the description of the CBR after the RSB.  Otherwise the reader 
would read the description of the CBR and still not have an 
understanding of what it is.  I was hoping the introduction in Section 
1, which gives the overview of how the session works and describes when 
the CBR is used would solve any confusion.  I'm not convinced that 
shuffling the sections as you have proposed will help.  But I can be 
convinced otherwise... perhaps somebody else has a take on this 
readability issue.

> clear what is "first bit" (could be first bit on the wire or bit 0).

Yup.  That makes it inconsistent.  I'll correct this.

> means the server will close the connection. I would really like to see

Perhaps some better text and words other than "yes/no" and 
"positive/negative" are in order.  I'll work on this.

And perhaps the values of the bits need to be redone.  The original 
idea was that a chunk descriptor octet of 0 is the normal termination 
of the block and easy to spot.  Perhaps that ideal isn't worth the 
price in understanding the rest of the bits in the descriptor.

> Closing, and the server will never say Keep Open.

I hadn't thought about it.  This is a good idea.  And something that 
ought to be applied to LWZ as well.

> chunks)? The introduction says a chunk is a (possible) fragment of an

It can.  In example 1, the second transaction shows both the request 
and response broken into 3 chunks.  In example 1, the response is 
broken into 3 chunks.

-andy

---

From: Robert Martin-Legene <[email-masked]>
Date: Fri, 20 May 2005 01:07:14 +0200

On 13/05/05, Andrew Newton <[email-masked]> wrote:
> shuffling the sections as you have proposed will help.

Maybe it can be solved by references to the sections which describe
the type. Is that ugly? It's just a little bit confusing first time
you read the document to find the first element of the protocol
described four pages after the introduction mentioning it.

Otherwise still move the section as I mentioned and then when you say
it's a type of RSB make a reference to the section which describes the
RSB.

And to make matters worse, the CRB is a subtype of an RSB, so maybe it
should be section 4.1.

It's a little bit like the chicken and the egg it seems.

> > it's
[...]
> price in understanding the rest of the bits in the descriptor.

I don't really think a value of 0 is that much easier than just to
logic AND and test the outcome. Which makes the software nicer anyway
at the cost of a single clock cycle extra or two. In perl - just for
you:

use constant CLOSING => 2**4;
exit if $header & CLOSING;

But - instead of shuffling values of bits around and changing
everything - including your value of 0 - how about just renaming the
flags? Or just call it Keep Open, if you are going to merge KO and CC
anyway.

> > I thought an entity could span multiple chunks
[..]
> and response broken into 3 chunks.  In example 1, the response is

You are right! I need glasses again, it seems. Sorry about that.

Your indentation looks wrong though? I'll use that as the reason for
my oversight ;-) Line 5 on page 25 needs an additional space after
"C:" ?

And then I got another worry I don't see mentioned in the security
section or elsewhere? How about people keep sending you chunk after
chunk in an infinate loop just because they don't like whichever
registry you happen to work for? You would keep allocating resources
until you die. I think it would make sense if the server closes the
connection if that happens, but if the size limitation is given in the
version information in the CRB then the client can probably figure out
why. Especially if the draft/rfc will say that the server should just
close the connection of the individual block gets bigger than the
maximum allowed size.

Not being an XML schema expert I tried to find this in the transport
draft but I couldn't see it described anywhere, hard as I looked. I
only see server-to-client size limits. There's a big chance I made a
mistake though.

(btw in the transport draft, I fell upon the words "mechanim" and "<verions>").

-- Robert Martin-Legène

---

From: Andrew Newton <[email-masked]>
Date: Fri, 20 May 2005 08:30:16 -0400

On May 19, 2005, at 7:07 PM, Robert Martin-Legene wrote:
> the type. Is that ugly?

That sounds like a good idea.

> And to make matters worse, the CRB is a subtype of an RSB, so maybe it

That's not a bad idea.

> exit if $header & CLOSING;

Of course you are right here.

> flags? Or just call it Keep Open, if you are going to merge KO and CC

Well, that pretty 0 is not worth the cost.  I'll work on this.  Your 
idea of combining the bits makes sense and will make things clearer... 
such as the example you just gave.

> close the connection of the individual block gets bigger than the

Well, I don't think this is so much a security concern but rather a 
detection of a bad client concern.

If I understand you correctly, you are worried that a client says "I 
have 95 octets to send" and then sends 100 more after the end of the 
block.  If the server is closing the connection after processing the 
block, I think it can just ignore the data.  If the connection is not 
being closed, then the server is not closing the connection, then it 
should start interpreting the data as the next RQB.  If the data is 
trash, then the RQB will not be interpreted correctly and the server 
should send a block error or data error (depending on where the data 
starts to look like trash, see section 7.3).  If a block or data error 
occur, my server will also set the "KO bit to close" (using the new 
terminology :) ) when it sends that block or data error and then close 
the connection.  Your server may be more forgiving.

-andy

---

From: Robert Martin-Legene <[email-masked]>
Date: Fri, 20 May 2005 22:55:40 +0200

> detection of a bad client concern.

Where's the limit between the two?

Is security a remote root compromise? Or a simple denial of service? 
Isn't it to secure your services to make sure they can handle
intentious bad client behaviour? (besides just malformed xml). Maybe I
am just too paranoid.. again.

> block.

Not after the block. I meant within the block. The usual
implementation of this kind would probably not start processing the
inner contents of the "xml entity" (or what is believed to be xml)
until the entire block is in (although one could do it word by word I
reckon - but that is uncommon). So I'll just keep sending you chunks
with the text "h4h4h4 y00 4r3 g3771|\|G pWn3d" without ever saying
that it's the last chunk. How will your implementation handle that?

-- Robert Martin-Legène

---

From: Andrew Newton <[email-masked]>
Date: Fri, 20 May 2005 18:13:54 -0400

> am just too paranoid.. again.

What I'm attempting to say is that if you follow the framing outlined 
by the protocol to catch poorly acting clients, you'll catch the cases 
where things like this happen instead of just buffering forever, 
overflowing stacks, etc...

> that it's the last chunk. How will your implementation handle that?

Well, now that you are making me strenuously think about this, there 
are four situations here... of which perhaps only three are covered:

1) Something in the way the chunk is described is wrong: well, that 
really only leaves the chunk descriptor which is one octet.  I think 
the draft talks about when to send block errors for these situations.

2) Something in the data of the chunk is wrong:  You read in the chunk 
descriptor and the chunk length.  This is three discrete octets.  The 
chunk length tells you how many octets to read next.  Once you have 
read in those bytes, you hand the data to your XML parser.  The 
complexity of this step depends on the capabilities of your XML parser, 
but there are at least 3 strategies: a) some XML parsers make this 
brain dead simple by offering a feed() function that just takes XML 
fragments (I believe Python, Perl, and libxml can do this), b) for 
parsers that are use to pulling the data from the source, a separate 
thread can be used for reading the socket and piping the data to the 
XML parser (this is the case for Java, fortunately NIO eliminates the 
potential for thread bloat here), and c) you just buffer it and hand 
the data to the parser after reading the last octet of the last chunk.  
No matter what, once the XML parser throws an exception, your server 
should send a data error (and perhaps close the session, depending on 
how nice you are).  When using strategies a or b, you can send this 
data error the moment the error occurs.  And if using strategies a or b 
and your server has already started responding with legitimate answers, 
you can still send a data error (by changing the chunk type).  If your 
server is nice and keeps the connection open, then you have to continue 
reading the block if you are using a or b.  But I don't see a point in 
being nice (lots of people can confirm this).

3) The chunk data contains XML with lots of ignorable whitespace: this 
isn't directly covered by the draft.  Technically, the ignorable 
whitespace should not cause your XML parser to reject the data, but I 
can see not wanted to accept 2000 octets of tab characters.  While a 
data error might cover that, we probably ought to define an error case 
that explicitly speaks to this.  Such as, "you have sent me an XML 
instance that is 900k long so far, perhaps you ought to get a hold of 
yourself".

4) The block contains lots of short, but very straightforward search 
sets.  Your server could just respond with IRIS <permissionDenied> or 
<limitExceeded> errors for every search set, or could use the new error 
code from #3.

-andy