[standards-jig] Version 0.3 of JEP-0046 / DTCP

[Jer]

I'm wondering, since what I understand to be the more-important subset 
of DTCP is simply a standard way to express the multiple potential IP's 
associated with an endpoint (multiple interfaces, SOCKS, fw's, NATs, 
PASS-like gateways, etc) is instead using a variant of 
jabber:iq:negotiate (jep-20) for that purpose alone.

Right now iq:negotiate works in the opposite direction of what is 
needed, so instead would it be wrong to do a get with no options, and 
the recipient return the list of options (ip's in this case)?  For 
example:

<iq type="get" id="1" to="jack at jabber.org/client">
   <query xmlns="jabber:iq:negotiate">
     <feature type="ip-addresses"/>
   </query>
</iq>

<iq type="result" id="1" to="jill at jabber.org/pda">
   <query xmlns="jabber:iq:negotiate">
     <feature type="ip-addresses">
       <option>1.2.3.4</option>
       <option>2.3.4.5</option>
       <option>11.22.33.44</option>
     </feature>
   </query>
</iq>

Then, when any app using any namespace need to know a list of IP's that 
might represent some other entity, there is one common way of asking 
and serving such information.

Is this pushing iq:negotiate beyond it's intent too far?

Jer

On Monday, September 23, 2002, at 03:58 AM, Ben Schumacher wrote:

> Justin-
>
...
>> It is quite possible I don't understand all of the implications here. 
>>  I am
>> not a security expert..
>
> I don't claim to be either, but I can still see a potential weakness in
> your protocol in the current proposal.
>
> Cheers,
>
> bs.
>
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig