Re: [mif] Adoption of API document as the MIF WG document

[Simon Perreault <[e-mail]>]

On 2011-12-20 08:48, [e-mail] wrote:
> I’m just trying to understand the scope of the MIF API and meaning of high/low
> level API.
>
> So, thinking about high-level requirements: IMU, the MIF API should address
> issues from the problem statement : DNS selection, source address selection and
> routing. Right? Considering these problems, the MIF API should be able to provide
> command/services to high level API (e.g. OMA-DM API), or even applications (if we
> imagine application with MIF management capabilities…). Typically, I’m thinking
> to the following requirements for the MIF API:
>
> DNS selection:
>
> -bound some DNS servers to an interface and suffixes.
>
> source address selection:
>
> -return the type of IP address (e.g. local, remote, mobile IP anchored
>
> -provide a valid IP address with a given type on a given interface
>
> routing / first-hop selection:
>
> -the API should allow to differentiate the traffic (i.e. provide capability to
> configure traffic selector)
>
> -associate a routing table per type of traffic

I think this is all low-level stuff.

Ideally, an application shouldn't have to deal with this stuff. It should be 
handled as automatically as possible by the stack. The high-level API should be 
as close to the "use case" as possible. For example, (I'm just inventing stuff 
now, not sure it makes sense), with an appropriate high-level API an application 
could just pass a flag saying "don't use a cellular interface".

The idea is that you don't want all apps to have to reimplement similar logic 
each time. The similar stuff can be abstracted away and put in the platform's stack.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca