[standards-jig] DTCP again

Jan Niehusmann jan at gondor.com
Fri Dec 13 17:08:08 UTC 2002


On Fri, Dec 13, 2002 at 08:48:39AM -0700, Dave Smith wrote:
> On Friday, Dec 13, 2002, at 05:23 America/Denver, Justin Karneges wrote:
> > I can link two clients together with just a few lines of code.
> 
> Yeah, maybe behind your own firewall. For the rest of us who live in 
> the "real world", NAT/Firewalls are a reality and something to be dealt 
> with. Just because it works for you doesn't mean it's sufficient to be 
> included in a widely-used standard such as Jabber.

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.

> > It's just that client developers have no interest.  Instead, they want
> > something that works today.  Is there any other reason DTCP would be 
> > at the  Last Call stage?
> 
> 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.

> > Sorry to weasel out of this last question, but IMO, the issue of proxy 
> > is  still a separate matter, and I would like to defer the issue.  DTCP 
> > was never meant to address it.
> 
> Then why did you even put it in your requirements section?

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

Jan




More information about the Standards mailing list