Bob, Joe,
Given this viewpoint, what guidance would you give, then, to protocol
designers who are writing specifications?
Eliot
On 3/30/11 8:09 PM, Bob Braden wrote:
+1
Bpb Braden
On 3/30/2011 1:11 AM, Joe Touch wrote:
Hi, all,
Perhaps we're not talking about an API, or even an abstract
On 4/5/2011 12:02 AM, Eliot Lear wrote:
Bob, Joe,
Given this viewpoint, what guidance would you give, then, to protocol
designers who are writing specifications?
IMO, we have never really explained what we expect in a protocol
specification. We focus on required sections like security
Hi -
From: Tom Yu t...@mit.edu
To: Sam Hartman hartmans-i...@mit.edu
Cc: i...@ietf.org; ietf@ietf.org
Sent: Wednesday, March 30, 2011 2:40 PM
Subject: Re: IETF and APIs
Personal observation: API is a subclass of interface. Network
protocol is a subclass of interface. Interfaces
- Original Message -
From: Joe Touch to...@isi.edu
To: Sam Hartman hartmans-i...@mit.edu
Cc: i...@ietf.org; dcroc...@bbiw.net; ietf@ietf.org
Sent: Wednesday, March 30, 2011 10:11 AM
Perhaps we're not talking about an API, or even an abstract API, but
just the application interface
Specifying the service interface a protocol provides (and what it
requires from other protocols) is often very useful. And is something
we have done in many cases.
Writing a set of subroutine definitions in some specific language is, in
my experience, usually far less useful.
As a related
On 3/30/2011 1:14 PM, Joel M. Halpern wrote:
Specifying the service interface a protocol provides (and what it requires from
other protocols) is often very useful. And is something we have done in many
cases.
In some cases, there is a surprising benefit:
It makes a clear distinction
On 03/30/2011 01:20 PM, Dave CROCKER wrote:
In some cases, there is a surprising benefit:
It makes a clear distinction between what is internal to the protocol,
versus what is payload that is delivered to the consumer (next layer up
or receiving application.)
Sometimes, the way a protocol is
Personal observation: API is a subclass of interface. Network
protocol is a subclass of interface. Interfaces (in the general
case) are valuable things to standardize. An abstract interface
(abstract API?) that gives guidance to implementors above and beyond
the bare specification of the
At the mic at the technical plenary last night, I made a comment that I
strongly supported the IETF doing API work.
I've realized that people may have assumed I meant that it would be
appropriate for the IETF to specify an API and not a protocol for some
given task.
That's not what I meant, so
On 3/29/2011 10:13 AM, Sam Hartman wrote:
At the mic at the technical plenary last night, I made a comment that I
strongly supported the IETF doing API work.
I've realized that people may have assumed I meant that it would be
appropriate for the IETF to specify an API and not a protocol for
On Tue Mar 29 09:53:32 2011, Dave CROCKER wrote:
I think that we should move more into that business.
I see no problem with actually specifying a language-specific API
when
the WG involved has the skills to do a good job.
Wow. What is the list of languages we should work on? C, C++,
Dave == Dave CROCKER d...@dcrocker.net writes:
Dave On 3/29/2011 10:13 AM, Sam Hartman wrote:
At the mic at the technical plenary last night, I made a comment that
I strongly supported the IETF doing API work.
I've realized that people may have assumed I meant that it
2011/3/29 Dave Cridland d...@cridland.net
On Tue Mar 29 09:53:32 2011, Dave CROCKER wrote:
I think that we should move more into that business.
I see no problem with actually specifying a language-specific API when
the WG involved has the skills to do a good job.
Wow. What is the list of
On 3/29/2011 11:17 AM, Sam Hartman wrote:
One level is the traditional protocol interoperability we normally
discuss.
Another level shows up when you want to write a cross-platform
application. It's not good enough if Windows has some API. I want to
have confidence that functionality is
Dave CROCKER d...@dcrocker.net writes:
The Other Dave C's highlighting the possibility of an abstract API
is also worth considering.
Yes. Today I would prefer to define abstract APIs in the IETF and let
implementers or other organizations map them to their language or
environment of choice
Would we not be better off just asking (mandating?) at least one open source
implementation? That effort would produce a de facto API.
On Mar 29, 2011, at 11:17 AM, Sam Hartman wrote:
Dave == Dave CROCKER d...@dcrocker.net writes:
Dave On 3/29/2011 10:13 AM, Sam Hartman wrote:
At
On Mar 29, 2011, at 1:28 PM, Eric Burger eburge...@standardstrack.com wrote:
Would we not be better off just asking (mandating?) at least one open source
implementation? That effort would produce a de facto API.
To co-opt wording from another thread, I think you are conflating an (even de
On 03/29/2011 01:28 PM, Eric Burger wrote:
Would we not be better off just asking (mandating?) at least one open source
implementation? That effort would produce a de facto API.
What you need is a reference implementation (i.e. an inefficient but complete
implementation, with a license that
On Tue Mar 29 12:28:55 2011, Eric Burger wrote:
Would we not be better off just asking (mandating?) at least one
open source implementation? That effort would produce a de facto
API.
Unfortunately this doesn't work in practise.
One of the examples that Sam raised originally concerned TLS,
Marc On 03/29/2011 01:28 PM, Eric Burger wrote:
Would we not be better off just asking (mandating?) at least one
open source implementation? That effort would produce a de facto
API.
Marc What you need is a reference implementation (i.e. an
Marc inefficient but
On 2011-03-29 at 12:08:55, Dave CROCKER wrote:
The Other Dave C's highlighting the possibility of an abstract API
is also worth considering.
You need to look at WebIDL http://www.w3.org/TR/WebIDL. This is what the W3C
use.
One size does not fit all language paradigms. You have to pick
On Tue, Mar 29, 2011 at 14:14, Dave Cridland d...@cridland.net wrote:
On Tue Mar 29 12:28:55 2011, Eric Burger wrote:
Would we not be better off just asking (mandating?) at least one open
source implementation? That effort would produce a de facto API.
Unfortunately this doesn't work in
On Tue Mar 29 16:53:03 2011, Scott Brim wrote:
On Tue, Mar 29, 2011 at 14:14, Dave Cridland d...@cridland.net
wrote:
On Tue Mar 29 12:28:55 2011, Eric Burger wrote:
Would we not be better off just asking (mandating?) at least one
open
source implementation? That effort would produce a
What we are really talking about here is
1) Defining the boundary between one layer and another
2) Specifying a means of reifying that boundary as something that is
concrete of which the most familiar form is an API
We discuss APIs all the time in IETF. Some examples:
We can't use X because
Sam,
Thanks for your comments about APIs. I have already had a very vibrant
debate with some folks about this in another context. I would simply
suggest here that the IETF has mixed success with APIs, especially
abstract APIs, and that while I wouldn't object to us going there,
given that we've
25 matches
Mail list logo
