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

audio streaming archive...

the temporary archive that the recordings are being dropped into is: http://ietf80streaming.dnsalias.net/ietf80/ the long term home as with all other recordings is: http://www.ietf.org/audio/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mai

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

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

auth48 changes to draft-ietf-behave-dns64

During auth48 of draft-ietf-behave-dns64-11.txt, it was realized that two sections were not consistent. The text in Section 5.1.1 is clear: If there is (non-excluded) data available, DNS64 SHOULD NOT include synthetic RRs in the response (see Appendix A for an analysis of the

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

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: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

+1. On 3/28/11 3:52 PM, Michelle Cotton wrote: > +1 > > Michelle > > > On 3/28/11 5:46 AM, "Lars Eggert" wrote: > >> As one of the authors/editors, I am fine with this change. Thanks! >> >> On 2011-3-28, at 14:14, Alexey Melnikov wrote: >>> After discussing this new text with IESG and some parti

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

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: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00

I think this encapsulates what Dave is trying to get across: Yes, it is MUCH easier for a server developer to stuff in a little more JavaScript. Now, you have a 100% proprietary system, with no hope or desire for interoperability, that gets deployed much faster than someone taking their extens

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: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00

Correct. The interoperability need shifts away from the client-to-server side (for example, to the server-to-server side; see Jonathan's plenary presentation slides) and to building blocks that are considered useful in various contexts. The BarBOF about JSON signing and encryption we had yest

Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00

On 3/29/2011 1:24 PM, Eric Burger wrote: I think this encapsulates what Dave is trying to get across: Yes, it is MUCH easier for a server developer to stuff in a little more JavaScript. Now, you have a 100% proprietary system, with no hope or desire for interoperability, that gets deployed mu

Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00

On 3/29/2011 1:31 PM, Hannes Tschofenig wrote: Correct. The interoperability need shifts away from the client-to-server side (for example, to the server-to-server side; No, that's wrong and I believe it is not what Eric said at all. THERE IS STILL A CLIENT/SERVER PROTOCOL, HANNES. ALL 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

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 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: auth48 changes to draft-ietf-behave-dns64

I'm OK with these changes. Jari Dan Wing kirjoitti: During auth48 of draft-ietf-behave-dns64-11.txt, it was realized that two sections were not consistent. The text in Section 5.1.1 is clear: If there is (non-excluded) data available, DNS64 SHOULD NOT include synthetic RRs in

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

Internet pioneer Paul Baran passes away

Sad news: http://www.bbc.co.uk/news/technology-12879908 -- Regards Brian Carpenter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: Internet pioneer Paul Baran passes away

On 3/29/2011 3:52 PM, Brian E Carpenter wrote: Sad news: Indeed. Katie Hafner ("Where Wizards Stay Up Late") did a very nice obituary, also: d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net

Request for public review of draft-yevstifeyev-ion-report-02

Hello all, I am writing to request public review of draft-yevstifeyev-ion-report-02, that cane be found at http://tools.ietf.org/html/draft-yevstifeyev-ion-report-02 The document is the report on IONs process experiment conducted by RFC 4693, as required by RFC 3933. As it was determined l

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: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00

On Tue, Mar 29, 2011 at 13:24, Eric Burger wrote: > Yes, it is MUCH easier for a server developer to stuff in a little > more JavaScript. > > Now, you have a 100% proprietary system, with no hope or desire for > interoperability There has to be interoperability in the system, but not at every int

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

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: Last Call: (Password Authenticated Connection Establishment with IKEv2) to Experimental RFC

Hi Dan, thank you for detecting this issue. We have just submitted a new version of the draft (http://tools.ietf.org/id/draft-kuegler-ipsecme-pace-ikev2-06.txt) that resolves it by fixing the length of the nonce and mandating the use of the corresponding unauthenticated encryption algorithm.

Re: For Monday's technical plenary - Review of draft-tschofenig-post-standardization-00

Got it in 1. On Mar 29, 2011, at 1:40 PM, Dave CROCKER wrote: > > > On 3/29/2011 1:31 PM, Hannes Tschofenig wrote: >> Correct. >> >> The interoperability need shifts away from the client-to-server side (for >> example, to the server-to-server side; > > No, that's wrong and I believe it is 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