Re: draft-ietf-impp-pres-01

General agreement.

If an application is forced to maintain context, that exposes a possible 
DoS attack.

#g
--

At 03:20 PM 1/14/03 -0800, Dave Crocker wrote:
>Thanos,
>
>My own opinion about the choice:
>
>If an identifier is being used only within a continuing context -- ie,
>very short-term usage -- then context-based identifiers are fine.
>
>As soon as the identifier has any complexity of use, either from having
>an extended lifetime or from being used across multiple contexts -- even
>when they are logically the same context but involve interruptions of
>service -- then self-identifying identifiers are much, much better.
>
>The concern about saving bits is usually not worth having dominate the
>design choice for such things, in application protocols.
>
>d/
>
>Tuesday, January 14, 2003, 12:31:13 PM, you wrote:
>Thanos> I was talking about the difference between context-based 
>uniqueness (what I
>Thanos> called the relaxed one - where the context is the 
>watcher/presentity pair)
>Thanos> and self-identified (which I think we called "globally unique").
>
>Thanos> In addition to the trade-offs mentioned below, there is also the 
>issue of
>Thanos> generating the extra bits for a self-identified unique identifier, 
>as well
>Thanos> as the burden of ensuring that this identifier is globally unique.
>Thanos> Whoever/whatever is generating those bits must have the means to 
>ensure
>Thanos> self-identified uniqueness.
>
>Thanos> Instead of arguing how much that burden is, I was wondering 
>whether there
>Thanos> are any reasons to go with a globally unique one, keeping in mind, 
>that
>Thanos> there is nothing that prevents us from using a globally unique 
>identifies,
>Thanos> in a specific To/From context.  It would still be unique.
>
>
>
>d/
>--
>  Dave <mailto:[email protected]>
>  Brandenburg InternetWorking <http://www.brandenburg.com>
>  t +1.408.246.8253; f +1.408.850.1850
>
>
>
>
>   [reminder: [email protected] for non-technical discussions, please]

-------------------
Graham Klyne
<[email protected]>




  [reminder: [email protected] for non-technical discussions, please]