[standards-jig] DTCP again

Ben Schumacher ben at blahr.com
Fri Dec 13 18:05:04 UTC 2002


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan Niehusmann wrote:
| DTCP only fails if both parties are behind broken NAT or firewall
| setups. Broken in the sense that they disallow a service the user wants
| to use.
|
| The fact that some people are unable to properly configure their
| networks is no reason to inhibit the developmentment of a
| widely-used standard such as Jabber.
|
| I think DTCP as proposed in revision 0.7 is a reasonable tradeoff
| between simplicity and completeness. If proxying can be added with
| little effort, go for it. If it would make DTCP too complex, leave it
| out.

This argument carries no weight. If you are trying to provide the best
end users experience, then the goal should be that I am always able to
establish a connection. I shouldn't need to "properly configure" my
network. The network I'm attached is configured in a way that is
appropriate for my use, whether by a network administrator, or by lack
of sufficient knowledge on my part. You mentioned earlier that you'd
like to be able to use DTCP to establish a remote login on somebody
else's box. Do you really think somebody that you aren't able to assist
remotely (either via voice, IM, email, etc) will have the knowledge to
"properly configure" their network?

|>DTCP is at Last Call stage because a couple of people proposed it as
|>such. That does _not_ mean it _should_ be at Last Call stage -- indeed,
|
| One could argue if DTCP should be in last call stage. But it obviously
| shows that there are some people interested in DTCP.

This by no means should be taken to signify that it is a technically
sound, or even the correct solution. It seems to me that people in the
Foundation who seconded the proposal are the same who have already
implmeneted the protocol, and those who seconded as a result of
campaigning. Frankly, if I had taken the time to implement the protocol,
I would probably have seconded as I wouldn't have wanted to see my work
go to waste. However, I never found it useful (for reasons I have
already stated ad nauseam), so I never implemented it, and therefore
felt no reason to second it.

| The following design goals are considered:
|
|     * The protocol should be reasonably effective in scenarios involving
|       NAT and/or firewalls. [1]
|     * It should be reasonably secure.
|     * Establishing a connection should be fast.
|     * The protocol should be simple.
|
| Proxies are not mentioned in the requirements section. Footnote 1
| states what's meant by 'reasonably effective'.

Fair enough, but I will maintain that this sollution is incomplete.
Placing that footnote in the document was simply a cop-out. It gives me
the impression that the problem that DTCP was proposed to solved, isn't
solved. It _sort of_ or _mostly_ solved, but it should be fairly obvious
at this point that while there are some members of the community feel
this is sufficient, there is a large(r?) group that feel it isn't. This
should be a pretty clear indication.

Frankly, it baffles me how you and Justin continue to be stubborn when
several members of the council have stepped forward to issue technical
objections to it. I feel that this JEP was inappropriately rushed to
Last Call, and if it does go to a vote, it will likely be rejected. Does
this really benefit the community?

As I believe has already been well stated previously, the council
advances JEPs when they have a sound technical foundation and enhance
the protocol as a whole. They do *NOT* (and should not) advance JEPs
solely because a few people have decided to implement a /proposed/
enchancement.

I realize that this may come across a little harsh, but I feel like
people have been skirting some of these issues and somebody needed to
step forward and state it. If anybody violently disagrees with me (read:
members of the council/foundation), please correct me, but I think my
interpretation is based on how why the Foundation was created to help
guide the community.

Cheers,

bs.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE9+iFPUpoGqensAXIRAvagAJ9yVnSNEN0upYmkg5Qw5D6utSummQCeJD6w
Lf2veERggv/OMsEpfcj+nHM=
=RqDz
-----END PGP SIGNATURE-----




More information about the Standards mailing list