Subject: [apps-discuss] New version of tn3270 draft

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 28 Nov 2010 12:06:27 +0200

Hello all,

A new version of tn3270 draft (-05) is now available on
the I-D repository. It includes the following changes:

-added the template for IANA to register the scheme as
  *Provisional*;
-added more detailed description of TN3270 service
  (with references to corresponding RFCs);
-added more references;
-added Acknowledgments section;
-another minor changes.

I am sending this message to Applications Area ADs -
Alexey Melnikov and Peter Saint-Andre in order they
can review this document.

Any suggestions for improvements are welcome.

Best regards,
Mykyta Yevstifeyev

---

From: Julian Reschke <[email-masked]>
Date: Sun, 28 Nov 2010 11:30:03 +0100

> Any suggestions for improvements are welcome.

Sunday morning nitpicking:

1) It's really confusing when you submit 3 drafts on the same day, and 
some of them only fix minor typos, or punctuation. That makes it hard to 
find out what actually changed. Also, draft -04 seems to have the wrong 
submission date.

2) A URI scheme definition that cites RFC 3986 only for security 
considerations makes me nervous. 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

3) ABNF comments

3a) What's the delimiter between password and host?

3b) What's the [/] at the end for? Did you mean [ "/" ]?

3c) Please avoid prose constructions; they are not sufficient to 
actually parse the URI. So which characters are allowed in "user", 
"password" and "host"?

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>.

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 28 Nov 2010 12:48:54 +0200

Hello Julian,

Here are responses on your notes.

28.11.2010 12:30, Julian Reschke wrote:
> some of them only fix minor typos, or punctuation. That makes it hard 
> to find out what actually changed. Also, draft -04 seems to have the 
> wrong submission date.
Now we are speaking about -05 draft.
> considerations makes me nervous. 
See section 1 - Introduction. There is not only one Sec. Cons. citing.
> 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.
> 3a) What's the delimiter between password and host?
I have mentioned that it is ":".
> 3b) What's the [/] at the end for? Did you mean [ "/" ]?
Yes, I meant ["/"]. Would be corrected.
> actually parse the URI. So which characters are allowed in "user", 
There is such information is Encoding considerations template section.
> <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.

All the best,
Mykyta Yevstifeyev

---

From: Julian Reschke <[email-masked]>
Date: Sun, 28 Nov 2010 12:09:30 +0100

Hi Mykyta,

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

More comments inline.

> 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).

> The scheme syntax is similar to 'telnet:'. The same recognition is

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

> I have mentioned that it is ":".

You mean, you will mention it?

> 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.

> 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

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 28 Nov 2010 13:26:48 +0200

Julian,

28.11.2010 13:09, Julian Reschke wrote:
> should define semantics and syntax in terms of the URI spec. (I 
> realize that some people may disagree).
>
Yes, it is just reusing. tn3270 is telnet3270 in fact. tn stands as 
acronym for telnet.
> You mean, you will mention it?
Yes, it will be mentioned.
> 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.
> 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:
>
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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 28 Nov 2010 12:38:21 +0100

On 28.11.2010 12:26, Mykyta Yevstifeyev wrote:
> ...
> ...

That doesn't seem to be a reply to what I said.

> ...

That would make the ABNF ambiguous. You need to exclude certain 
characters so that the other components can be detected. Again, by any 
means, have a look at RFC 3986.

> ...

OK, in that case you should say that non-ASCII characters in the host 
name component should be treated as per the IRI spec, Section xyz.

> spec. to this document. It is Normative only.

OK, let's agree to disagree on this one :-).

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 29 Nov 2010 16:42:06 +0200

Hello all,

A new version of the tn3270 draft is available (-06). This
version took into account many Julian's proposals (see
below). Among other:

-ABNF for the scheme was updated,
-References were divided into Norm. and Inf.
-other minor changes.

The link:

http://www.ietf.org/id/draft-yevstifeyev-tn3270-uri-06.txt

Any suggestions and comments are welcome.

All the best,
Mykyta Yevstifeyev