Re: IETF and APIs

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 con

Re: IETF and APIs

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 a

Re: IETF and APIs

Hi - > From: "Tom Yu" > To: "Sam Hartman" > Cc: ; > 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

Re: IETF and APIs

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 t

Re: IETF and APIs

+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 API, but just the "application interface" (or just "upper layer service" specification). RFC793 is a great example that a protocol provides a service, and that service

Re: [IAB] IETF and APIs

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

Re: [IAB] IETF and APIs

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 b

Re: [IAB] IETF and APIs

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 not

Re: IETF and APIs

... RFC793 is a great example that a protocol provides a service, and that service needs to be explained - and that explaining it does NOT need to be done in a specific language. ... And yes, it is still one of the great RFC; is that because it describes something that became rather popular o

Re: IETF and APIs

- Original Message - From: "Joe Touch" To: "Sam Hartman" Cc: ; ; 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" (or just "upper layer service" > specification). > > RFC793 is a grea

Re: IETF and APIs

Hi, all, Perhaps we're not talking about an API, or even an abstract API, but just the "application interface" (or just "upper layer service" specification). RFC793 is a great example that a protocol provides a service, and that service needs to be explained - and that explaining it does NOT

Re: IETF and APIs

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'v

Re: IETF and APIs

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 Jav

Re: IETF and APIs

On Tue Mar 29 16:53:03 2011, Scott Brim wrote: On Tue, Mar 29, 2011 at 14:14, Dave Cridland 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 AP

Re: IETF and APIs

On Tue, Mar 29, 2011 at 14:14, Dave Cridland 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 practise. >

RE: IETF and APIs

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 . This is what the W3C use. One size does not fit all language paradigms. You have to pick

Re: IETF and APIs

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 bu

Re: IETF and APIs

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,

Re: IETF and APIs

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

Re: IETF and APIs

On Mar 29, 2011, at 1: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. To co-opt wording from another thread, I think you are conflating an (even de facto) API with an applicati

Re: IETF and APIs

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 writes: > >Dave> On 3/29/2011 10:13 AM, Sam Hartman wrote: >>> >> >> At t

Re: IETF and APIs

Dave CROCKER 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. The IETF is no

Re: IETF and APIs

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 avail

Re: IETF and APIs

2011/3/29 Dave Cridland > 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

Re: IETF and APIs

> "Dave" == Dave CROCKER 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

Re: IETF and APIs

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++, Java

Re: IETF and APIs

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

IETF and APIs

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