Re: Fwd: A comment about MAST

[Dave Crocker <dhc@dcrocker.net>]

Eugene,

>> As for a "MAST API", none is needed.
>> 
>> MAST hides the multiple addresses from transport and above.  That is one of
>> its features.

EMK> I see.  Looks like I misunderstood MAST in that sense. =)

The first draft of the proposal was rather confusing, about a number of
issues.  Please let me know if the second draft (released last night) is more
clear about this.


>> Also, as soon as the application needs to benefit from knowing about -- and
>> giving guidance about -- the availability of multiple addresses, then it needs
>> an be nice to enhanced API. That is true for any multi-addressing solution,
>> not just MAST.

EMK> Also agreed.

EMK> A random idea: How about making MAST support these two operating mode?

EMK> 1. The original scenario, where the transport layer such as TCP does not
EMK> know how to handle multiple endpoint addresses nor requests MAST to
EMK> notify about address changes.  MAST operates as originally proposed in
EMK> this case.

EMK> 2. The new scenario, where the transport layer such as TCP knows how to
EMK> handle multiple endpoint addresses and requests MAST to notify about
EMK> address changes.

This sounds like a very good proposal to me.  A core API that is backward
compatible -- in fact, it _is_ the old API.  And then an extended API for the
extended functionality.


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>