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

[Marcos Sanz/Denic <[e-mail]>]

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 
connection/
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,
Marcos

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