[Standards] RTT, take 2

Kevin Smith kevin at kismith.co.uk
Wed Jun 22 15:52:53 UTC 2011


I've performed a quick review of the new proposal. I have a handful of
comments on the spec; I don't currently intend these to be blocking,
for my part, when Council vote to Experimental. I consider this a vast
improvement over the first proposed version of the document.

I apologise if my thoughts aren't as coherent as they might be, these
were made while going through it and haven't been wordsmithed.

4.2.2 Why SHOULD 0 (rather than MUST)?

4.2.3.3 - Start shouldn't be used for discovery, disco/caps should.

4.2.3.4 - Cancel would be more consistent with other specs

4.3.2 Seems inappropriate - we should only be suggesting UI
behaviours, where they're not security critical, not mandating them.

4.5.1.1 insert is ambiguous - what does 'at position p' mean?
	Forward delete should be explicitly rightwards, if that's the intent.
How does this play with RTL languages?

4.5.1.3 Why are we dealing with utf-16 when everything is mandated utf-8?

4.5.2.1 Discussions of counting whitespace scare me where whitespace
isn't significant
	Would benefit from real numbers, and an example, I think. Ah,
examples in section 6. Could do with a forward reference.

4.5.2.6 We already have a spec for this

4.5.3 What does an empty rtt mean?
	Tier 2 being SHOULD isn't compatible with 4.5.2.6 saying it's OPTIONAL
	I have a feeling that we need to normalise, not relying on
transmission being unmodified.

4.6.2 MUST here seems overzealous, best efforts seem reasonable given
the ultimate <body> correction.

5.1.1 Non-normative recommmended.
	SHOULD NOT here seems overzealous again.

5.2.1 seems like an implementation note
5.2.2 Non-normative SHOULD NOT
5.2.3 Non-normative SHOULD
	Shouldn't be describing the programming model used
5.4.1 Where does this maximum stanza size come from?
	Why do you need the final transmission? An earlier section says MUST
be ignored, IIRC.
All of 5 seems to be implementation notes, in fact

6.9 - not sure the note about sums-to-1 is beneficial.

8. Should not be using UTF-16

Security considerations might note that this scheme breaks FLOT labelling.

/K



More information about the Standards mailing list