[Crisp] My Last Call Comments on iris-xpc-04

Marcos Sanz/Denic <sanz@denic.de> Fri, 25 August 2006 17:39 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGfes-0006Tl-NL; Fri, 25 Aug 2006 13:39:54 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGfeq-0006Sq-SX for crisp@ietf.org; Fri, 25 Aug 2006 13:39:52 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGdk6-0007wq-H4 for crisp@ietf.org; Fri, 25 Aug 2006 11:37:10 -0400
Received: from smtp.denic.de ([]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGdW8-00077D-8X for crisp@ietf.org; Fri, 25 Aug 2006 11:22:49 -0400
Received: from notes.rz.denic.de ([]) by smtp.denic.de with esmtp id 1GGdW1-000513-0I; Fri, 25 Aug 2006 17:22:37 +0200
To: crisp@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005
From: Marcos Sanz/Denic <sanz@denic.de>
Message-ID: <OFB5213F2A.8CDC9B1A-ONC12571D5.005056D0-C12571D5.00547474@notes.denic.de>
Date: Fri, 25 Aug 2006 17:22:30 +0200
X-MIMETrack: Serialize by Router on notes/Denic at 25.08.2006 17:22:36, Serialize complete at 25.08.2006 17:22:36
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: iesg@ietf.org
Subject: [Crisp] My Last Call Comments on iris-xpc-04
X-BeenThere: crisp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Cross Registry Information Service Protocol <crisp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/crisp>, <mailto:crisp-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:crisp@ietf.org>
List-Help: <mailto:crisp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/crisp>, <mailto:crisp-request@ietf.org?subject=subscribe>
Errors-To: crisp-bounces@ietf.org

Hello Andy,
Hello all,

Here they come, it's all mainly nitpick:

Title, Page 1: s/Information Registry Information Service/Internet 
Registry Information Service/ (nobody has seen that before?!)
Section 1: s/descretion/discretion/
Section 3, 2nd bullet: s/the length of the authority field/the length in 
octets of the authority field/
Section 3, 3rd bullet: The sentence starting with "The number of octets in 
this string MUST..."  is unnecessary.
Section 4.1: s/RSB will may/RSB may/
Section 4.1: s/the clients TCP buffers/the clients' TCP buffers/
Section 4.2: s/keep-open/keep open/ (to match the definition in section 5)
Section 5: The sentence starting with "The bits are ordered according..." 
is unnecessary, since it's already mentioned in the document terminology.
Section 5: s/and to indicate that a connection/or to indicate that a 
Section 5, KO flag: I'd like to see some text like "The server MAY honour 
the KO request of the client".
Section 6: The sentence starting with "The bits of the chunk descriptor 
octect are ordered.." again IMHO redundant.
Section 6, 2nd bullet: s/with out/without/
Section 6, 4th bullet: s/'oi type/'oi' type/
Section 6: s/contingous/contiguous/
Section 6: s/interpretted/interpreted/
Section 6: s/chunks must by/chunks MUST be/
Section 6: s/than one type/than one type./
Section 6, 3rd element of the numbered list, about "information chunks": 
'si' type is missing
Section 6: s/at least one type of the above/at least one kind of the 
above/ (to avoid confusion with the term "type" regarding chunks)
Section 6: s/the length of the data/the length in octects of the data/
Section 6.2: s/specified in [10]/specified in IRIS-COMMON [10]/ (since 
that is the format used later on)
Section 6.2: "and MUST have the <versions> element as the root element" is 
not true in the case of client queries for 'vi', because they are empty.
Section 6.2, <dataModel>: s/IRIS registries/IRIS registry types/
Section 6.4: I am not sure that the 5th kind of "block-error" should be 
signalised as a "block-error", they are a different kind of information. 
All other four cases imply that th e server has received something wrong, 
and this 5th kind implies that there's something that the server hasn't 
got at all. It would be helpful for e.g. debugging, if the error were 
different (e.g. "chunk-timeout").
Section 6.4: About the recommendation of 2 minutes for this timeout, I 
think that's operator policy and shouldn't be recommended here.
Section 6.4: s/terminating chunk/chunk with LC=1/
Section 6.5, title: s/SASL Types/SASL Data Types/ (to match the 
nomenclature in section 6)
Section 6.5: s/SASL chunk type/SASL data chunk type/
Section 6.5: s/the length of the SASL mechanism name/the length in octects 
of the SASL mechanism name/
Section 6.5: s/the length of the SASL data/the length in octects of the 
SASL data/
Section 6.5: s/the length of the SASL profile name minus one/the length of 
the SASL mechanism name minus three/ (if I got the count right and if Sam 
doesn't mind enough)
Section 6.5: s/mechansim/mechanism/
Section 7: The same comments than before about timeout recommendations: I 
think they are operator policy and thus wouldn't like to see that "5 
minutes" in there.
Section 12: After having read the examples (none of which have a encoding 
declaration) I think it would be helpful to add some text here like: 
"Since XPC doesn't provide encoding information by itself, it is an error 
for an XML entity including an encoding declaration to be presented to the 
XML processor in an encoding other than that named in the declaration, for 
an encoding declaration to occur other than at the beginning of an 
external entity. It is also an error for an entity which begins with 
neither a BOM nor an encoding declaration to use an encoding other than 
UTF-8. Note that since ASCII is a subset of UTF-8, ordinary ASCII entities 
do not strictly need an encoding declaration."
(that's mainly copied from the XML specification, maybe add a reference).
Section 13.1: s/RFC2396/RFC3986/
Section 13.4: s/secure XPCS/XPCS/
Appendix A: No client chunk contains the XML declaration. I know it's 
optional, but it's strongly recommended, thus I would add it in every 
single chunk. The encoding declaration is not necessary.
Appendix A: I'd drop all schemaLocation hints from the clients requests. 
They are optional, they are distracting.
Appendix A: Also distracting is the use of "temporaryReference" in the 
responses (they contain no references!). Let's drop it.
Appendix A: s/succss/success/

And I am still digesting RFC 4422, so I can't come up with specific 
recommendation regarding SASL, yet, sorry.

Best regards,

Crisp mailing list