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

[Mykyta Yevstifeyev <[e-mail]>]

Julian,

28.11.2010 13:09, Julian Reschke wrote:
> 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.
Yes, it is just reusing. tn3270 is telnet3270 in fact. tn stands as 
acronym for telnet.
>
>>> 3) ABNF comments
>>>
>>> 3a) What's the delimiter between password and host?
>> I have mentioned that it is ":".
>
> You mean, you will mention it?
Yes, it will be mentioned.
>
>>> 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.
I'll put smth. like 'user = *VCHAR' there.
>
>>> 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?
Generally HOST is an IP address and it is will be very few
cases when THIS scheme will be used with internationalized
DNS names.
>
> 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.
We import a section (or a part of a section) of telnet scheme
spec. to this document. It is Normative only.
>
> Best regards, Julian
>
All the best, Mykyta