[I'm catching up a bit late... The discussion was about APIs] On Thu, 2005-01-27 at 11:17, ext Kurt Erik Lindqvist wrote: > On 2005-01-26, at 21.04, Erik Nordmark wrote: > > I read Marcelo's comment as a more application layer thing, i.e. a > > question whether we should work on an abstract API (not a binding to a > > particular programming language) which applications can use to > > - observe what is going on below (which locator pair is used now? > > what interface - GPRS or 802.11 - is being used?), > > - express preferences (don't even try over GPRS type things) or some > > other way to control things [...] > > I don't see a need to add anything about this to the charter though. > > Ok, I think I misunderstood Marcelo then. However, I would assume that > at least some text on application layer 'events' should be included in > either the architecture or the protocol document? There might be a bit more to this than just application layer events. I'd think that many systems might still want to use the conventional socket API for shim6 communication. Would the semantics of the traditional socket API functions be affected? Take bind(), for example? Would it still be possible to bind to a selected locator/IP address (and what would that mean), or would bind work on an ULID level, as one would expect if there was a new address family? Even though APIs are not generally in the IETF scope, it might be worth it to discuss possible interactions with the traditionally used APIs, and what applications can expect from the behavior of the underlying shim6. Don't know if this would be a charter issue, though, or could it be included in the other planned documents, if considered useful. - Pasi
Attachment:
signature.asc
Description: This is a digitally signed message part