Re: [apps-discuss] [Uri-review] New version of tn3270 draft

[Julian Reschke <[e-mail]>]

Hi Mykyta,

so indeed I managed to look at -04, and didn't notice. Apologies.

More comments inline.

On 28.11.2010 11:48, Mykyta Yevstifeyev wrote:
>> 2) A URI scheme definition that cites RFC 3986 only for security
>> considerations makes me nervous.
> See section 1 - Introduction. There is not only one Sec. Cons. citing.

OK, but that doesn't really help. I think a URI scheme registration 
should define semantics and syntax in terms of the URI spec. (I realize 
that some people may disagree).

>> For instance, it should be clear how the individual components would
>> be recognized by a generic URI parser. It appears that all you're
>> saying that the scheme-specific part maps to:
>>
>> "//" authority
> The scheme syntax is similar to 'telnet:'. The same recognition is
> intended.

Please have a look at RFC 3986 and consider just re-using the syntax 
from over there, if it matches.

>> 3) ABNF comments
>>
>> 3a) What's the delimiter between password and host?
> I have mentioned that it is ":".

You mean, you will mention it?

>> 3b) What's the [/] at the end for? Did you mean [ "/" ]?
> Yes, I meant ["/"]. Would be corrected.
>>
>> 3c) Please avoid prose constructions; they are not sufficient to
>> actually parse the URI. So which characters are allowed in "user",
>> "password" and "host"?
> There is such information is Encoding considerations template section.

Actually, that is not the case. The ABNF needs to say what the character 
repertoire for these parts is, and the prose needs to state whether 
there's an escaping mechanism that can be used to map more characters 
into this syntax.

>> 4) You're not citing the URI scheme registration RFC (4395), nor have
>> the information requested in
>> <http://tools.ietf.org/html/rfc4395#section-5.4>.
> Why not mentioned? See section 4 of the draft - IANA Cons. The full
> template is given.
>>
>> Best regards, Julian
>>
> All notes seem to conform -04 draft. Maybe you are looking at html
> version, which
> is not formed yet. Look at plain text version.

As I said, I looked at the wrong version; but as you see above, part of 
my notes apply to the current version as well.

Furthermore:

    URI scheme encoding considerations: tn3270 scheme uses UTF-8 (see RFC
    3629 [RFC3629] for details) for encoding data. No internalization is
    intended

URIs do not contain non-ASCII characters. What you *could* say is that 
if the URI is built from components that *do* allow non-ASCII 
characters, such as the username, you need to map them to octets using 
UTF-8. But then you say "no internalization is intended"? What is it? 
How does IDNA work here?

Also, in the Normative References, you may want to check whether all of 
these are normative. For instance, the "telnet" scheme is only cited in 
the security considerations section, so I don't see why it would be 
normative.

Best regards, Julian