Session Date/Time: 13 May 2026 14:00
Barry Leiba: Okay, we've got the top of the hour. Looks like we have critical mass, so let's get started. I was hoping that Christian would be on, but he's not. That's okay, so I'm on my own chairing. Let me start by saying that the goal here today is to get this ready for get EDN literals ready for Working Group Last Call. And so the plan the chairs have is that whatever we discuss today can get can result in a document update, we'd like that to be submitted by Monday. And we can start Working Group Last Call on Monday and that will help us determine whether we have consensus for what's in there. And the plan would be for that to be about a 10-day Working Group Last Call. And Michael, you said ahoy, is there something?
Michael Richardson: No, I'm just chairing, that's all.
Barry Leiba: Oh, got it.
Michael Richardson: Good plan, let's go, let's do it. Yes.
Barry Leiba: Okay. So if we cannot determine consensus that there is rough consensus for what's in there with this Working Group Last Call, then that tells us that we're not being functional and we need to abandon the documents and re-evaluate what's going on. So really, this is a push for everybody to work this toward a rough consensus, whether it's your preferred answer or not. Can you live with what's there? What needs to happen if you can't? Specifically, what changes are needed? That's where we're going today and through the Working Group Last Call. So, Carsten, you have some slides? Hit it. Let me give you the thing here. There we go.
Carsten Bormann: Okay. So I was hoping we can do this EDN literal thing in half an hour so we have a little bit of time for partial implementations, but that plan may of course fail. So where are we? There is a -24 out there that no longer has any open issues. There is one open pull request, but that doesn't just drop in, it's essentially a complete overhaul of the document, so it's not exactly what I would want to do at this point in time. It's also a regression of the - yeah, so that's the current status of the document. I made one mistake. I left the editor notes in the abstract for -23. So I'll probably do a -25 in any case, but we could see whether there's anything then just this editorial fix in there. So I want to quickly talk about what PRs we closed or single PR we closed and then bring up the subject of naming which has come up on the mailing list and I think is pretty interesting because we essentially haven't discussed this for two years and it may be a good point in time to actually do this now. So on the closed PRs, Roman had put in a PR 102 that makes the range check for the simple syntax syntactic instead of semantic. One can do it this way, it's maybe even the IETF way of doing this way, so I thought this doesn't really hit us in any specific way. So I merged the thing and then I noticed that it wasn't complete, so I did a few additional changes and it's now complete. And I used the opportunity to add some boilerplate text for editorial conventions that most CBOR standards have in one way of the - yeah, so this should be non-controversial and it's not a big change. I think it's two new paragraphs for the conventions and a few deleted items in the text about simple. So that's that. So what is this naming discussion? So for the last two years or so, we have used well, the title is a bit newer, but the rest of the things on this slide are two years old. We have used the term Extended Diagnostic Notation in most of our writing and discussion, or CBOR Extended Diagnostic Notation abbreviated to EDN. But then the media type is called application/cbor-diagnostic, the RFC editor source code type is cbor-diag, and the file extension is .diag. So it's not particularly consistent, and while we are using this little cacophony of terms, maybe other people are not. So maybe it's worth just looking at it again. I'm not going to make any suggestions on what we are going to do with the RFC editor source code type because that has been in there now for five or six years, so changing that would be a big thing. But I just want to keep it on this table on the other versions of this table so we know what the end result will be. So this is choice zero. We just stick with what we have, and that was my default assumption until people started alerting on the mailing list that we probably should think about this. Now, why want to revisit this? First of all, this spec has evolved. It started as a rather focused project and got a lot of new objectives added. So it's just worth looking at the name again. Also, the term extended really is no longer useful. I mean, I'm doing this conference using extended HTTP over extended TCP over extended IP over extended Ethernet. Extended is really not a particularly useful thing to have in a protocol name and it always sounds like, "Oh, if there is an extended something, what is the non-extended something?" So if there is an EDNS, what is DNS? And so this is pretty confusing to people who haven't been subject to this name for a long time already. So yeah, that might be one reason to get rid of extended. On the other hand, people have been using the abbreviation EDN, so let's see. The other observation is that the diagnostic notation actually is useful in other contexts as well, even if the objective is not to simply generate CBOR, but maybe to do something different. So yeah, some applications may not want to have the name CBOR in there. And the last observation is that .diag is not very googlable. I'm not sure that is a problem, but it has been named as a problem, so we may want to think about googlability of all these terms. Yeah, I left out one point. EDN is the name for the text-based representation of data in the Clojure programming language. That may not be something that a lot of people in this working group are familiar with, but people who come from the computer science side are likely to know Clojure and wonder which EDN is this which here. So one approach would be to simply get rid of the diagnostic name as much as possible in the abbreviations, so we would continue to use EDN as an abbreviation but use the media type cbor-edn and a file extension .edn. So that would be really going for EDN all the way. It has the problems I talked about, but it's at least something that people are not going to struggle with. Is cbor-diagnostic the same thing as EDN and so on and so on and so on. So that's one way. We can also just take out the word CBOR. So the version one here, the idea one, has CBOR still in the title and in the media type, but we could take that away and say we now have an Extended Diagnostic Notation and we are not going to tell you on the title page what it's good for. And the media type also would just say application/edn. File extension would of course also be .edn. So this would be going EDN all the way and then a little further by de-emphasizing that it is coming out of the CBOR context. And I'm reading Roman's recent draft about representing instances of the TLS presentation language in EDN as something that might benefit from making this extra step. Yeah, then the other avenue here is trying to get rid of the vestigial extended in the name. So we have two words we never should use in a protocol name, one is simple and the other is extended. And yeah, so number three here, idea number three says let's call it just CBOR Diagnostic Notation. And yes, it's more than was in 2013 in RFC 7049, but yeah, that's the fate of protocols that they get extended. So the media type would be cbor-cdn, which is kind of redundant, it's like an LED display, but I think we have learned to live with LED displays. And the file extension would be .cdn. People have noticed that CDN has other meanings. Just about every three-letter acronym has other meanings, so we are not going to get rid of that problem. And finally, we could do the de-emphasize CBOR thing to this approach as well and just use the word concise which we always use if we don't know how to call things and call this the Concise Diagnostic Notation, also CDN, do not use the word CBOR in the media type and use the file extension .cdn. So if we have a preference among the audience of this meeting, I would love to hear it. We're probably not going to decide this in this room. My approach to solving this would be to take any direction from this room if we get one, otherwise we stay with zero and we make this one of the questions that should be asked in the Working Group Last Call, what we are going to do with the name. But that's for the chairs to decide how how we actually do that. Yeah, so there are new proposals, I cannot make a slide five, six, seven and so on. And let me just give an anecdote here. When we named CDDL, we got immediate feedback that's the name of a license that Sun Microsystems subjects much of its open software to. Yes, but that's irrelevant and the interesting positive effect was that given that CDDL had this this Google hit, nobody else called anything CDDL, so we now have that name for ourselves. So the results can be a little bit different or inverse to what one would think about that conflicts are not necessarily a bad thing, in particular if they actually point to something entirely different. Okay, do we have other things resolved? I don't know, I'm not aware of any issues or pull requests except the one I talked about that is not actionable at this point in time. And we have had two years since the IESG sent back the document to us to work on this, so yeah, I don't know. We will only find out in a Working Group Last Call. Any comments on zero, one, two, three, four? Discussion, no discussion? Okay. Laurence?
Laurence Lundblade: Uh, CDN is fine for me. I agree with a lot of what you said about extended and about diag confusing things. Uh, CDN is lines up nicely with CDDL too, uh, and I'm really not fussed about the name collision on CDN with whatever else is out there, so I think CDN's an improvement, but uh, I don't have a really strong feeling either way, so.
Carsten Bormann: So are you in favor of three or in favor of four?
Laurence Lundblade: Either one works.
Carsten Bormann: Okay, good. That's useful input and thanks Mikolai for also providing input. I can probably disclose that I'm also in favor of number four. Mikolai?
Mikolai Gütschow: Uh well, my preference is that the abbreviation should be unique so that people won't confuse it with anything else. Uh, so to insert another letter to the CDN like CEDN or EDNC or maybe CBORDN these are all short enough and unique enough. But just three letters I think too short to be distinguish - well, I want it to be distinguishable, yes, distinguishable even at abbreviation level.
Carsten Bormann: Thank you. Any other feedback? Yeah, we probably should do a quick check on the mailing list as well, but again we have the Working Group Last Call to actually collect the - CBDN. Okay, so what does the B standing for? Not binary.
Laurence Lundblade: Yeah, sorry to jump in. I don't know, I didn't think too hard. Um, short for CBOR somehow. Um, CBD is cool these days, everybody uses CBD, I don't know.
Barry Leiba: Cannabidiol, yeah. Keeping in mind that as Carsten mentioned everything has a collision somewhere, there's no no abbreviation is unique.
Carsten Bormann: Okay. So yeah, let's send a quick message to the mailing list after the meeting and report on where we got in this meeting, but I think that has been useful input. So with that, I think we can keep Barry's deadline of getting a -25 out there by Monday or earlier than that. And that should complete this item except if Barry wants to say something more.
Barry Leiba: No, I think we're done.
Carsten Bormann: Laurence, you have something to add?
Laurence Lundblade: Yeah, I have not tracked the discussion about the backticks and all of that and I don't really know where that landed. Um, not my thing about the the one thing I really have to say about that is have we really done implementations of it? Like are there, you know, a lot of the argument was about how hard or how easy it is to implement this and um, seems like a good way to do that would be to to build some really good implementations and not not prototypes or just like slam it together and say like see, I mean, some someone that's a serious implementer that that like built an implementation with test cases and stuff like that to to kind of prove the point, you know, build it both ways, you know, and compare the code or something. But build it thoroughly um to to really understand. I mean, I um you know, I think we've turned up in in CBOR itself in RFC 8949, we've turned up things that uh if we had done more thorough implementations, we would have maybe done things more differently. Um, so that's my comp comment is like let's try for some really thorough implementations rather than the usual just, "Yeah, I did it" kind of thing, you know. Implementations that maybe everybody can look at and see something to be sure we're really, you know, getting there.
Carsten Bormann: Yeah, to answer the question, I know of two implementations. So I did a full implementation with test vectors and all that. And Joe has checked whether he can implement that, so he he has actual code. I don't know whether he has released that because this was still something that is being discussed in this working group and Joe had a lot of other things to do recently. Um, so that's the current state. So my implementation is in Ruby, Joe's is in JavaScript/TypeScript. Um, and it certainly would be interesting to hear from from other people. Yeah, so Vadim points out that if you have a lexer-parser combination like like in flex and bison or lex and yacc, it's pretty trivial to implement this, um but I haven't done it. So but on the other hand, all major programming languages except for the C language itself now have some equivalent to this, have something that we could be calling raw strings. The JavaScript templates are not quite the same thing, but it's at least solving a similar problem and the other languages just essentially did what C++ and other languages did, which is very close to what we did here. Okay, thank you Laurence, that was a good question. Okay, so I'm not now going to the next item. So partial implementations. I think that's a pretty interesting result of the discussion that we were having. We really seem to understand at this point much more than we did maybe two or three years ago that we have to discuss partial implementations. And so what's important about here? First of all, CBOR is supposed to go into very, very simple devices. That's not the only application, so capable devices should struggle with this question much less, but if you have a simple device, you don't want implementation complexity that that doesn't give you anything. And the observation here is these were mostly data model constraints. So what implementers find out that is that the platform types they are trying to map the CBOR types to - and I'm sorry, I should have mentioned we are not talking about diagnostic notation here anymore, we are talking about real CBOR. So the platform types that that you use for representing CBOR may be a good fit for for 80% of CBOR, but there may be some something left. And if that is not being used by any of the application data models relevant for for this implementation, then it makes sense to accept the partial implementation as a really good implementation. So since we have talked about floating point so much, I just made this little set or sequence of six different ways to implement floating point. Floating point is a part of the basic generic data model of CBOR, so one would expect it to be in there, but if I have a device that doesn't need floating point, doesn't have floating point instructions and doesn't even use a floating point library, why on earth should I implement this? So a no-float partial implementation is something that that is very obvious to people who have been in the early days of CBOR. I don't think we even have discussed this because it's so obvious that you want that. But there may be other steps on on the way to full IEEE 754. So for instance, I made an implementation in Elixir and Elixir only has finites, finite floating point values. Elixir also doesn't guarantee that it uses IEEE 754, but I think that's not really a realistic complaint anymore, so everybody uses IEEE 754. Um, so Elixir would what without help by the implementer be in position two on this list. And yeah, we have other implementations that that go a little bit further to the right and so on. So the point here is I'm trying to make is this is about the data model, this is about what does the application need in terms of data items that are in the data models and if the applications that a particular implementation is interested in do not use a part of the data model that doesn't have a good mapping to the platform types, then we are making the life of the implementer hard. So that's I think the summary of what we learned from the CDE discussion. Now what I really would like to avoid is that we do a profiles formal kind of thing for CBOR. So let's say we have six levels of partialness and we have F0, F for floating point, F0 has no floating point, and F9 implements CBOR and everything between that are just random guesses of what people might want to have in their partial implementation. So those people who know about floating point will already say, "Wait a minute, what about platforms that only have a binary 32 support and no binary 64 support?" Right, that's why it's not easy to go ahead and do a profiles formal style description of the partialness of implementations. So yes, we could do that, but yeah, if we can avoid it, I would be happier. So this whole discussion came up in the context of discussion of serialization and serialization constraints. And what we learned from the CDE discussion is that implementations may benefit a lot from one constraint that is not a data model constraint but a serialization constraint, the definite-length only constraint. And I must admit, I didn't think about that in 2013 when we put indefinite length into CBOR, we knew that this is additional work for implementers, we have heard metrics like 40% more work or something. So unless you really need this for memory management and synchronization and whatever point, then you should be really in a position where you can pay for this feature. And we did not address this in any way in a way that people can handle this or know that they need to handle this when doing a protocol definition. So that's something we should be fixing. What we also found there aren't really other serialization constraints that aren't also data model constraints. Now, I didn't try to map the whole poor man's CDE discussion onto these slides because that would have busted my slot here. But really serialization constraints is not a particularly useful thing to do on the partial implementation side because in the end, if you are trying to use this as a poor man's CDE, poor man's deterministic encoding, you are relying on the sender to send the right kinds of data to you to do your own validation and annotation of incoming data. And that's not what you want to do, I think we have learned in the last 20 years. Um, yeah, so in any case deterministic encodings are a special case here in the world of serialization constraints because the benefit of making a serialization constraint accrues outside the world of partial implementations. This is not about partial implementations, this is about having some some property of the implementation of always generating the same serializations. So this is different from "I don't want to do this particular part of serialization." So I think it's interesting to look at interoperability because the whole point of doing all this is of course interoperability. And we really have to distinguish between serialization constraints that are imposed unilaterally in the encoder or bilaterally by having a serialization constraint in the decoder that the encoder must be aware of and the encoder must implement to be able to work with this decoder. And the only serialization constraint where we found significant benefit of having it available as an option is definite length only. So I think it's really important to distinguish between the unilateral constraints that any implementer can do without needing to talk to all the other implementers and bilateral constraints that actually affect the interoperability of the protocol. Laurence.
Laurence Lundblade: Yeah, um I'm going to ask you to please let's note the whole notion, when you say we, um I consider that your opinion, not an established consensus or something like that. And I'm actually pretty strident about this because for a couple of years when I listened to you talk, you said we, I believe there was some big group of people that had formed consensus, and until I'd been here for two years, I did not understand that that we was not any kind of consensus, it was just your opinion. And for new people that come in and show up here, they think, you know, they're sort of cowed by that. So I'm actually pretty strident about the use of that term we.
Carsten Bormann: Yeah, thank you for correcting me that that's a good point. Okay, so there are two pieces of ugliness that we dug out by talking about serialization constraints. One is this weird data model overlap between major type 0/1 and the tag 3 serializations. And my view on this is that should be implemented. And my view on this is also that we should never do this ever again with another tag. So that was a mistake, a mistake that is hard to correct at this point in time, but that we don't want any other tags to actually fight with as well. So excuse me, we have learned something here and I think that what we have learned leads to these two conclusions, but that's my personal point of view. The other thing is the map key equivalence that many people know as section 5.6.1 even if the section 5.6.1 does a lot of other things as well. So there are a lot of platform types that are very good for representing CBOR maps on the platform that actually treat zero floating point and minus zero floating point as identical with respect to the key position in the map. So if your decoder implements map key checking, it needs to consider this equivalence. So that's also additional code, I think we have different ideas of how much additional code that is. And we also have different ideas of how useful map key checking as a decoder service is, but of course if your platform type really does this to you and creates this equivalence of positive zero and negative zero, your code will somehow have to handle that. So yeah, that's ugly but it's also something that cannot be simply swept away because it's the way we are doing things right now. So I wanted to mention these to point out it's not all easy and simple here, we have two things that require some additional effort from implementers, and my objective here would be to minimize the effort that is required to do this. Okay, so with that, um it was quite interesting for me to look back those those 12 or 13 years and see what did we actually write into the document to help implementers avoid partial implementations. And the first seven years or so, we only ever gave examples for decoders because it really is the job of the decoder not to create partial implementations that have a bilateral effect. So we want to help people doing a full implementation, again we are talking about implementations that happen on the serialization side and do not have an impact on the data model because as soon as the data model is concerned, of course the data model needs to fit to the application. So the first seven or 10 years we have been talking about examples for decoders and only in the CDE document we got an example - and we is really the document that we had for a while - gives an example for an encoder. So this example is useful for people who actually want to support for instance preferred serialization as a unilateral decision, but it's only needed for CDE, so it came up in the context of CDE. Yeah, I know Laurence. Um, it came up in the context of CDE because it's actually needed there, it's not needed in CBOR without deterministic encoding. Okay, so this is my technical point I was trying to make. Now we might exploit this observation by adding some structure. And we want to discuss partial implementations, I think that's important and I laud Laurence's work on on understanding what those partial implementations are and how we might want to deal with them. And one objective here is to guide application protocol developers. So this I only had a floating point example on on my slide, there's also similar consideration for integer examples. So the fact that CBOR in its basic generic data model can cover integers from minus two to the 64 to plus two to the 64 is also something that is not necessarily easy to map to implementation types. So some guidance for protocol developers, for instance using the CDDL types that since have found a way on the the useful CDDL wiki, that might be something that is useful for application protocol developers. On the serialization side, yeah, you know what the objective of of the CDE document was, so make information accessible and condense them in one place, so people who want to avoid creating interoperability problems on the serialization side have that information available and also get maybe some tips and tricks for their implementation. So that's that's the structure in which I think we should be thinking about this problem and separate the serialization issues which do exist, but maybe are not as comprehensive as it sometimes seems from the partial implementation issues, which also do exist, but are much less entangled to the serialization questions than our previous discussion might have given impression of. So that's my summary, that's food for thought, I don't think we will make any decision about this today except that Laurence is right that I should not include the working group until we have had a formal consensus call. And um yeah, maybe we can can go into the long weekend, in Europe it's a long weekend, sorry Laurence, thinking about this a little bit and seeing how we can structure this guidance in such a way that we are not entangling serialization with partial implementations. And I'm done. Laurence.
Laurence Lundblade: Okay, um I have a kind of a lot to say here. Um, you know, I did a survey um back in November of what um different what the major CBOR implementations did and you know, to see what they left off and what they you know, and and it was, you know, it was interesting to see, I think it's still probably in the in the mailing list. Um, they uh, you know, some left off floating point, some left off big nums, some left off indefinite lengths, um some some did partial parts of float, um I don't I should probably summarize it, but um, you know, and the question's like why are they doing partial implementations and what you know, how are we framing partial partial implementations. And um, you know, I think you're right that that sometimes partial implementations leave off data types that are unnecessary or difficult, particularly big numbers and floats. Um, big numbers is probably the thing that's left off the most. But I don't I really find the distinction between um the data types and the serialization to be uh um not useful, I think it's academic, it's a for a you know, protocol average protocol implementer outside of this discussion, um most of them aren't even aren't even aware of like what the difference between not supporting indefinite length and not supporting floating point, I think they're not even thinking about that in that in that way, you know, you just think about the unwashed masses of people that use JSON, I mean it's just they don't think about that kind of stuff, so this is all very to me this is all very um kind of uh it's detailed that undermines our progress, undermines the the use of CBOR and the universality and the adoptability of CBOR if we continue with these these discussions about all these sort of detail and we manifest it um up into the the you know, the rest of the CBOR community, it it keeps CBOR kind of uh I don't know, too fussy and too detailed. I mean CBOR has a ton of features actually, you know, you compare it to JSON, CBOR is way more complicated than JSON, and you know, JSON's probably main the main reason for its success and wide adoption is it's so simple and so straightforward to understand, you can look at the look at it and understand it in uh you know like half an hour, I mean that JSON.org is a you go look at that and you you got the idea. Um, CBOR is so fussy and so detailed uh that uh you know, and we keep we keep well, I mean Carsten I think you keep adding details and and you know terminology and stuff like that and and so I would like to see us try to go the other way. And um in terms of, you know, partial implementation, uh you know, I think I've made a couple of lists there uh on the mailing list, like you know and categorized, you know where people do partial implementation and you know there's some some of it's data types, some of it is uh serialization stuff and some of it is validation stuff. So there's there's like three main things uh that people do partial implementation for. And I and I just think it's partial implementation, I don't see the point of distinguishing serialization stuff from the data type stuff from the range checking stuff from the validation stuff, I don't see the point in that, I think it's just too fussy. Um I uh been thinking I would characterize um you know, there's kind of a a set of CBOR features that most implementations um support um and uh the the sort of the sweet spot of what they use and what the libraries support. Um and this is, you know, fairly similar to what the capabilities of JSON are. Um if you kind of look at that that sort of subset that uh that overlaps with JSON, you know that's what that's how people model their data, it's how people are used to representing their data, so all these extra things um they're they're kind of uh nice extra capabilities but libraries don't implement them and protocols probably don't use them, so there's there's kind of a sweet spot in there, and you know that sweet spot is is you know 64-bit integers um strings, arrays, maps with keys that are just integers or strings, sometimes float um and sometimes the basic simple simple types. Um and it's definite length only um indefinite lengths is so things like indefinite lengths, big numbers, nan payloads, things that people don't don't use and they don't need, you know. So we can understand that there's a reasonable subset that you can implement tons and tons and tons of protocols with you don't need everything that that CBOR has to implement like most of the protocols that people come up with and design because we know that because people have been of how the huge amount of use that JSON has. Um and the other thing I want to say is that you know I'm not like I mean Anders kind of seems to have this idea that there needs to be one CBOR for that's universal everywhere. Um I'm making more the observation that there is a subset of CBOR that is highly useful that kind of similar to what JSON uses and similar to what you see if you if you were to to take the common subset of what all the CBOR libraries implement, there's a subset there that's very useful and fairly easy to implement. Um the point is to sort of converge on something like that and the serialization document kind of does that um but not to say that this is the only way to do it, to say this is the main way to do it and if you've got special needs then go you know you want your fancy map keys, you want your indefinite lengths, yeah CBOR is great it has all these extra things too if you want them but you don't have to do them and most you know if you do them and then if you design a protocol to use them then you have to be a little more discerning about which libraries you use and you're putting yourself out there a little further out there so okay.
Barry Leiba: I think I I said something of this nature last well two weeks ago on the call that we make need to make a distinction if you're sending CBOR, you send what you want and if you don't need pieces of it, you don't have to do them. But on the receiving end if you don't implement understand all the pieces, then when something comes along that sends you something you don't understand, you're confused or you throw an error or whatever it is. Um so I mean isn't pretty much everything we design that way that any protocol, any format, whatever the sender implements the pieces of it that they find useful but the receiver has to be able to understand all of it? And and I think that's common across many different protocols and data formats, etc, etc. And I'll just add we I have to I have a call right after this one, so we need to wrap this up.
Laurence Lundblade: Yeah Barry, I don't think that's true, I actually think that's a I think that's a problem, um the and the problem comes in that implementing the decoding all of CBOR is way too costly, you can't do that. Um the complex map keys, the you know people don't want to implement floating point, people don't want to implement big numbers, I mean I I know this first hand, I mean I'm working in C with no library support, I'm trying to implement everything um in CBOR and I mean I'm years into years of work to try and do that, to get the basic CBOR stuff working yeah you can do it in a few weeks, to to to understand and do everything in 8949 with clean APIs, that's years.
Barry Leiba: Okay, um I think we'll have to say that that's the last word on this call and we'll take this back to the list and continue the discussion. So Carsten, you're going to have a 25 version of EDN literals very soon and we'll plan to start a Working Group Last Call after that's posted. And um you'll see all of that on the list. Um is there anything you just want to say in a minute that to wrap this up?
Carsten Bormann: Yeah, so given that we had a relatively rough but discernable direction in terms of renaming, I was going to to jump the gun as people generally like to to accuse me of doing and do this new naming in the -25 that we will use for the Working Group Last Call.
Barry Leiba: Yeah, I think that would be fine and we can use the Working Group Last Call to make sure that everyone can live with that. Okay, thanks everybody and um we'll see you back on the list.
Carsten Bormann: Thank you.