Re: SHOULD and RECOMMENDED
They are not synonyms Lets go back to 1980: Implementations SHOULD support DES vs RECOMMENDED encryption algorithms: DES, IDEA There are many specifications that specify crypto algorithms that should not. JOSE and XML Signature should not have required algorithms or even SHOULD language. The protocols that are built on the specifications are where the normative language belongs. On Sun, Jun 23, 2013 at 6:00 PM, Dave Crocker d...@dcrocker.net wrote: On 6/22/2013 10:28 AM, Barry Leiba wrote: I believe that it would be wise to discourage RECOMMENDED and NOT RECOMMENDED as synonyms for SHOULD and SHOULD NOT unless they are clearly necessary to avoid awkward sentences and the non-A/S intent is completely clear. A fine suggestion, with which I agree. For normative vocabulary, synonyms are sinful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Website: http://hallambaker.com/
Re: IAOC Website Updated
Hi, Ray. I also think it's good. On the same theme as Brian, the page is linked to from the 'IASA' link on the main IETF page. To make it clear what is going on, it would be good to put the title: IETF Administrative Support Activity at the top of the page. A couple of other nits: It might also be useful to add 'IASA/IAOC' to the header of the Announcements page. The 'Legal' and 'Subpoenas' pages contain significant duplication: The text in the 'Subpoenas' section of the 'Legal' page is a large subset of the text on the 'Subpoenas' page. Conversely, the 'Appeals' page under operations misses the text on the appeals process in BCP101 that is hidden under the 'Legal' page. Regards, Elwyn On Mon, 2013-06-24 at 16:36 +1200, Brian E Carpenter wrote: Hi Ray, I think it's very good. One micro-comment: the menu at the left is headed up by the IETF logo (which is in fact a link to the main site). I did find that momentarily confusing - maybe the first two items could be labelled IASA Home and About IASA to make it clear which menu this is? Best wishes Brian On 21/06/2013 06:59, IETF Administrative Director wrote: One of the IAOC goals for 2013 was to update the IAOC website to improve consistency, organization, linkage, and ease of use. I am pleased to announce that the IAOC site has been updated and is available now for your use at http://iaoc.ietf.org/. On the home page see a video of an Overview of the IAOC given by Chair Bob Hinden in Orlando that includes a discussion of venue selection and IETF finances. Also on the home page are recent announcements, as well as reports from IANA, the RFC Editor, the IETF Chair, the NomCom Chair, and more. The navigation bar makes it easy to find financial statements, minutes, meeting sponsorship opportunities, and much more. We hope you find this helpful, the IAOC as more transparent, and of course we welcome your feedback. Ray IETF Administrative Director PS: Going to IETF 87 in Berlin? The IAOC will be doing another overview session there, Sunday July 28 at 3:00 PM. Hope to see you there!
Re: SHOULD and RECOMMENDED
--On Monday, June 24, 2013 07:52 -0400 Phillip Hallam-Baker hal...@gmail.com wrote: They are not synonyms Lets go back to 1980: Implementations SHOULD support DES vs RECOMMENDED encryption algorithms: DES, IDEA Actually, that is the point. The usage above, although much earlier, reflects the Protocol Specification/ Applicability Statement split rather well. But 2119's language makes the two terms substitutable for and equivalent to each other, which is about as close a definition of synonyms as one can find. What I said is that making them equivalent was probably a mistake and that treating them that was should be discouraged. Others expressed agreement with that assessment. Personally, I don't think the problem is severe enough to reopen 2119. If others disagree and believe that 2119 is generating enough problems to be worth an update, I await a draft. So, other than quibbling about the synonym issue -- not generally, which no one has claimed, but in context with 2119-- are you disagreeing and, if so, about what? john
Re: Is the IETF is an international organization? (was: IETF Diversity)
On Wed, Jun 19, 2013 at 4:40 PM, Ted Lemon ted.le...@nominum.com wrote: On Jun 19, 2013, at 3:18 PM, Yoav Nir y...@checkpoint.com wrote: Yeah, and act is what Americans call statutes, and Selma is a city in Alabama where there was some controversy about voting rights. You sure need to know a lot of Americana to participate meaningfully in some of these discussions. Sorry. That was directed largely at Melinda who is, to the best of my understanding, an American. The point was that in fact the civil rights movement started with individuals, not the government. It would have been easier to note that the technological terror we have created has been one of the drivers behind the Arab Spring. Before that Communism was defeated through a bottom up movement: People just walked away. I seem to remember that there is a country in North America where the foundation myth is based on the claim of a bottom up revolt but I can't quite recall which one. Something to do with tea. -- Website: http://hallambaker.com/
Secdir review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05
Please treat these comments as normal last-call comments. I've been asigned as a security directorate reviewer for this draft. This draft specifies a mechanism to indicate which packets were discarded in a RTP stream. for the most part, this doesn't seem to have any security implications, and the text is clear. I do have one concern. Has the WG analyzed implications of providing feedback to an attacker on what specific SRTP packets are discarded? In the past we've run into trouble with security systems that were too verbose in error reporting. As an example, in certain public-key crypto constructions knowing whether a packet produced a decoding error vs a signature error after decryption can provide an attacker generating forged packets valuable information to attack the system. It's quite possible that SRTP doesn't have problems in this regard. I just want to confirm that the analysis has been done.
IASA contracts (was: IAOC Website Updated)
The IAOC states that The IASA site is designed to provide the IETF community with transparency into the fiscal and administrative activities of the IAOC. According to the IAOC minutes: The IAOC approves a two-year extension of the Legal Services Contract with Contreras Legal Strategy LLC and requests the Internet Society to enter into such agreements as to effect this extension. The motion passed. Randy [Bush] abstained because he had not seen the contract. The Contracts webpage ( http://iaoc.ietf.org/contracts.html ) does not contain most of the contracts which were signed by the IAD. The IAD previously mentioned that the contracts will be published after the last meeting. Regards, -sm
Re: SHOULD and RECOMMENDED
On 6/24/2013 8:39 AM, John C Klensin wrote: --On Monday, June 24, 2013 07:52 -0400 Phillip Hallam-Baker hal...@gmail.com wrote: They are not synonyms Lets go back to 1980: Implementations SHOULD support DES vs RECOMMENDED encryption algorithms: DES, IDEA Actually, that is the point. The usage above, although much earlier, reflects the Protocol Specification/ Applicability Statement split rather well. But 2119's language makes the two terms substitutable for and equivalent to each other, which is about as close a definition of synonyms as one can find. What I said is that making them equivalent was probably a mistake and that treating them that was should be discouraged. Others expressed agreement with that assessment. Personally, I don't think the problem is severe enough to reopen 2119. If others disagree and believe that 2119 is generating enough problems to be worth an update, I await a draft. So, other than quibbling about the synonym issue -- not generally, which no one has claimed, but in context with 2119-- are you disagreeing and, if so, about what? john In my view, a SHOULD is just a highly RECOMMENDED mode of operation, the preferred mode, the mode that SHOULD be enabled out of the box. The conflicts I see is whether the usage of a SHOULD means it really is a MUST be implemented as described and the exception is when there is no other alternative available. A common reference is use EHLO first, fallback to HELO. What is often forgotten is the ON/OFF configuration aspect. So even if there is a MUST implement SHOULD thinking, the question is whether there is an allowance to disable or turn off the feature, i.e. can an SMTP server disable EHLO and operate in pure RFC821 (STD10) mode? The answer to the question is yes, its possible, and therefore all implementations MUST be ready in operate in SMTP (821) mode FIRST, ESMTP mode second. I think the dilemma is that we have new integration needs and in some cases, one protocol or set of integrated protocols simple works better when a traditional optional technology i.e. SMTP extension, is used. So there is a mindset, it seems, a SHOULD is really a MUST and only under extreme situations, the alternative can be used, if presented. -- HLS
Re: IASA contracts (was: IAOC Website Updated)
On Jun 24, 2013, at 12:34 PM, SM wrote: The IAOC states that The IASA site is designed to provide the IETF community with transparency into the fiscal and administrative activities of the IAOC. According to the IAOC minutes: The IAOC approves a two-year extension of the Legal Services Contract with Contreras Legal Strategy LLC and requests the Internet Society to enter into such agreements as to effect this extension. The motion passed. Randy [Bush] abstained because he had not seen the contract. The Contracts webpage ( http://iaoc.ietf.org/contracts.html ) does not contain most of the contracts which were signed by the IAD. The IAD previously mentioned that the contracts will be published after the last meeting. Progress is being made. The ICANN SLA for 2013 has been published. The Verilan Master Services Agreement 2013 has been published. Both the Secretariat and the RFC Production Center contracts are under review and I expect them published in the next two weeks We have more to do and appreciate the continuing community interest in and feedback on what we do. Thanks Ray PS Hope to see you in Berlin Regards, -sm
RE: SHOULD and RECOMMENDED
my feeling and belief is that RFC 2119 only gives SHOULD and RECOMMENDED the same normative requirement level, but that it does not override or change the distinct meanings of these words in English. sentences using each of these terms have different meanings in English, even when those sentences appear in RFCs. -michael thornburgh From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John C Klensin Sent: Monday, June 24, 2013 5:40 AM --On Monday, June 24, 2013 07:52 -0400 Phillip Hallam-Baker hal...@gmail.com wrote: They are not synonyms Lets go back to 1980: Implementations SHOULD support DES vs RECOMMENDED encryption algorithms: DES, IDEA Actually, that is the point. The usage above, although much earlier, reflects the Protocol Specification/ Applicability Statement split rather well. But 2119's language makes the two terms substitutable for and equivalent to each other, which is about as close a definition of synonyms as one can find. What I said is that making them equivalent was probably a mistake and that treating them that was should be discouraged. Others expressed agreement with that assessment. Personally, I don't think the problem is severe enough to reopen 2119. If others disagree and believe that 2119 is generating enough problems to be worth an update, I await a draft. So, other than quibbling about the synonym issue -- not generally, which no one has claimed, but in context with 2119-- are you disagreeing and, if so, about what? john
Re: SHOULD and RECOMMENDED
On 6/24/13 1:47 PM, Michael Thornburgh wrote: my feeling and belief is that RFC 2119 only gives SHOULD and RECOMMENDED the same normative requirement level, but that it does not override or change the distinct meanings of these words in English. sentences using each of these terms have different meanings in English, even when those sentences appear in RFCs. I expect that the subtle differences between these words are lost on non-native speakers, and even most native speakers, of English. I'd be genuinely curious to hear that you think the distinct meanings are. Peter -- Peter Saint-Andre https://stpeter.im/
Re: SHOULD and RECOMMENDED
The mistake I was attempting to avoid here was concluding that RECOMMENDED should not be used. It does have a necessary use that is distinct from SHOULD. Given the number of citations it gets, I am sure someone will be willing to volunteer to do a revision if Scott Bradner is not interested. On Jun 24, 2013, at 8:39 AM, John C Klensin john-i...@jck.com wrote: --On Monday, June 24, 2013 07:52 -0400 Phillip Hallam-Baker hal...@gmail.com wrote: They are not synonyms Lets go back to 1980: Implementations SHOULD support DES vs RECOMMENDED encryption algorithms: DES, IDEA Actually, that is the point. The usage above, although much earlier, reflects the Protocol Specification/ Applicability Statement split rather well. But 2119's language makes the two terms substitutable for and equivalent to each other, which is about as close a definition of synonyms as one can find. What I said is that making them equivalent was probably a mistake and that treating them that was should be discouraged. Others expressed agreement with that assessment. Personally, I don't think the problem is severe enough to reopen 2119. If others disagree and believe that 2119 is generating enough problems to be worth an update, I await a draft. So, other than quibbling about the synonym issue -- not generally, which no one has claimed, but in context with 2119-- are you disagreeing and, if so, about what? john smime.p7s Description: S/MIME cryptographic signature
Re: SHOULD and RECOMMENDED
On 6/24/2013 12:52 PM, Peter Saint-Andre wrote: I expect that the subtle differences between these words are lost on non-native speakers, and even most native speakers, of English. I'd be genuinely curious to hear that you think the distinct meanings are. I suspect you are wrong... In your implication that there is /any/ meaningful distinction made by native English speakers when reading an RFC... For the times I've seen the different words used normatively in RFC, I have not discerned any semantic difference. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: SHOULD and RECOMMENDED
On Jun 24, 2013, at 10:52 PM, Peter Saint-Andre stpe...@stpeter.im wrote: On 6/24/13 1:47 PM, Michael Thornburgh wrote: my feeling and belief is that RFC 2119 only gives SHOULD and RECOMMENDED the same normative requirement level, but that it does not override or change the distinct meanings of these words in English. sentences using each of these terms have different meanings in English, even when those sentences appear in RFCs. I expect that the subtle differences between these words are lost on non-native speakers, and even most native speakers, of English. I'd be genuinely curious to hear that you think the distinct meanings are. It is RECOMMENDED that implementations send the AUTH_LIFETIME notification at least 4 minutes before the SA is to be deleted, to facilitate the user entering credentials in time. The implementation SHOULD send the AUTH_LIFETIME notification at least 4 minutes before the SA is to be deleted, to facilitate the user entering credentials in time. - What are the subtle differences in meaning between these two sentences? - Would an implementation written by a native speaker be any different depending on which of the above sentences was in the RFC? Yoav
Re: SHOULD and RECOMMENDED
On 6/24/13 2:08 PM, Dave Crocker wrote: On 6/24/2013 12:52 PM, Peter Saint-Andre wrote: I expect that the subtle differences between these words are lost on non-native speakers, and even most native speakers, of English. I'd be genuinely curious to hear that you think the distinct meanings are. I suspect you are wrong... In your implication that there is /any/ meaningful distinction made by native English speakers when reading an RFC... For the times I've seen the different words used normatively in RFC, I have not discerned any semantic difference. I agree. (It would have been better for me to say subtle differences, if any.) I'm open to an argument that in standard English should has a shade of obligation and recommended has a shade of suggestion, but in practice (especially in RFCs) those shades are lost. Peter -- Peter Saint-Andre https://stpeter.im/
Re: SHOULD and RECOMMENDED
On 6/24/13 12:18 PM, Yoav Nir wrote: - What are the subtle differences in meaning between these two sentences? I think I recommend is rather clearly different from you should, in terms of strength and (in the case of normative text) obligation. I don't think that recommend is useful in the context of an RFC, may be confusing and a bit subtle, and is probably best avoided. Melinda
Re: SHOULD and RECOMMENDED
I read SHOULD and RECOMMENDED as different. SHOULD is how a implementation ought to behave unless there are special circumstances (deployment, additional functionality, better idea). MUST says that there are no circumstances special enough to change the behavior. RECOMMENDED is closer to a Best Current Practice (BCP); so I might write It is RECOMMENDED that the network-converged timer have a minimum value of 2 seconds. but in 10 years, maybe it'll only take 2 microseconds - so that'll become a bad recommendation! Alia On Mon, Jun 24, 2013 at 4:23 PM, Melinda Shore melinda.sh...@gmail.comwrote: On 6/24/13 12:18 PM, Yoav Nir wrote: - What are the subtle differences in meaning between these two sentences? I think I recommend is rather clearly different from you should, in terms of strength and (in the case of normative text) obligation. I don't think that recommend is useful in the context of an RFC, may be confusing and a bit subtle, and is probably best avoided. Melinda
Re: SHOULD and RECOMMENDED
--On Monday, June 24, 2013 16:28 -0400 Alia Atlas akat...@gmail.com wrote: I read SHOULD and RECOMMENDED as different. SHOULD is how a implementation ought to behave unless there are special circumstances (deployment, additional functionality, better idea). MUST says that there are no circumstances special enough to change the behavior. RECOMMENDED is closer to a Best Current Practice (BCP); so I might write It is RECOMMENDED that the network-converged timer have a minimum value of 2 seconds. but in 10 years, maybe it'll only take 2 microseconds - so that'll become a bad recommendation! And that, again, is close to the distinction that a reasonable person might read into 2026. But not into 2119 which appears (at least to me) to make them fully-substitutable alternatives. The distinction doesn't make the comments made by Peter, Dave, or others any less valid. If we told ourselves that readers should (lower case) infer conformance statements from SHOULD and applicability ones from RECOMMENDED... well, we would be pretty delusional. john
Re: SHOULD and RECOMMENDED
while I like to take credit for the good things in RFC 2119 (and disclaim the bad things) - the term RECOMMENDED (good or bad) comes from RFC 1122 basically I copied the definition section from RFC 1122 for the 1st version of what became RFC 2119. (see http://www.sobco.com/ids/draft-bradner-key-words-00.txt) based on mailing list discussion I produced two revisions of the ID (mostly to add guidance on usage) http://www.sobco.com/ids/draft-bradner-key-words-01.txt and http://www.sobco.com/ids/draft-bradner-key-words-02.txt the 02 version is what was approved by the IESG as RFC 2119 all of the above is to say that I can not help in this discussion about the difference between SHOULD RECOMMENDED other than the fact they represent different parts of speech maybe Bob Braden has an idea since I do find not a usage of RECOMMENDED in the RFC series before RFC 1122 Scott On Jun 24, 2013, at 4:38 PM, John C Klensin john-i...@jck.com wrote: --On Monday, June 24, 2013 16:28 -0400 Alia Atlas akat...@gmail.com wrote: I read SHOULD and RECOMMENDED as different. SHOULD is how a implementation ought to behave unless there are special circumstances (deployment, additional functionality, better idea). MUST says that there are no circumstances special enough to change the behavior. RECOMMENDED is closer to a Best Current Practice (BCP); so I might write It is RECOMMENDED that the network-converged timer have a minimum value of 2 seconds. but in 10 years, maybe it'll only take 2 microseconds - so that'll become a bad recommendation! And that, again, is close to the distinction that a reasonable person might read into 2026. But not into 2119 which appears (at least to me) to make them fully-substitutable alternatives. The distinction doesn't make the comments made by Peter, Dave, or others any less valid. If we told ourselves that readers should (lower case) infer conformance statements from SHOULD and applicability ones from RECOMMENDED... well, we would be pretty delusional. john
Re: IASA contracts (was: IAOC Website Updated)
Hi Ray, At 12:22 24-06-2013, Ray Pelletier wrote: Progress is being made. The ICANN SLA for 2013 has been published. That's a zero-cost contract. I don't have any problem with the IANA folks I interact with. They are nice and they do what they say they will do. That's more important to me than a SLA. The Verilan Master Services Agreement 2013 has been published. Both the Secretariat and the RFC Production Center contracts are under review and I expect them published in the next two weeks Thanks. I prefer specific dates instead of ambiguous time frames. We have more to do and appreciate the continuing community interest in and feedback on what we do. I presume that this message is from IASA. What I find unusual is that a member of the IAOC is being asked to agree to a contract without being given the opportunity to read the contract ( http://www.ietf.org/mail-archive/web/ietf/current/msg80269.html ). I note that the member was selected by NomCom and that the person is doing the IAOC work as a volunteer. According to RFC 4333 Candidates for these IAOC positions should have knowledge of the IETF, knowledge of contracts and financial procedures. I don't know which procedures IASA is following that make it acceptable to blindly agree to contracts. There was a RFP for Remote Participation Services Specifications Development. There were the IDIQ contracts which were mentioned over two years ago. There was the Requirements for Data Tracker Extensions for Working Group Chairs and Author contract. I did not elaborate about all the contracts in my previous message as I assumed that it was about all the contracts. I do not have any vested interest in those contracts. I am okay about answering any questions the IETF Community may have about my vested interests. PS Hope to see you in Berlin It's unlikely that I will be able to make it to Germany. Regards, -sm
Re: SHOULD and RECOMMENDED
On 6/24/2013 1:23 PM, Melinda Shore wrote: I think I recommend is rather clearly different from you should, in terms of strength and (in the case of normative text) obligation. I don't think that recommend is useful in the context of an RFC, may be confusing and a bit subtle, and is probably best avoided. A number of the notes have offered personal views about the differences between the two words. No doubt each of us could offer such comments. And perhaps some of us might even offer similar meanings. Unfortunately, the ability of one person to impart their own semantic distinction is irrelevant to the current discussion, which is about normative language used for global standards that are read by widely and wildly different people around the world, with extreme differences in English language skills. This is technical specification, not literature. Subtlety and nuance -- especially of a linguistic nature -- is wholly inappropriate. Just as we find simpler technology propagates better across the Internet, so does simpler specification language. MAY/SHOULD/MUST has proved simple and sufficient. Any gradations beyond that have demonstrated no utility for IETF specifications. Hell, we still debate the differences of just /those/ 3 words... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: SHOULD and RECOMMENDED
On 25/06/2013 08:38, John C Klensin wrote: --On Monday, June 24, 2013 16:28 -0400 Alia Atlas akat...@gmail.com wrote: I read SHOULD and RECOMMENDED as different. SHOULD is how a implementation ought to behave unless there are special circumstances (deployment, additional functionality, better idea). MUST says that there are no circumstances special enough to change the behavior. RECOMMENDED is closer to a Best Current Practice (BCP); so I might write It is RECOMMENDED that the network-converged timer have a minimum value of 2 seconds. but in 10 years, maybe it'll only take 2 microseconds - so that'll become a bad recommendation! And that, again, is close to the distinction that a reasonable person might read into 2026. But not into 2119 which appears (at least to me) to make them fully-substitutable alternatives. The distinction doesn't make the comments made by Peter, Dave, or others any less valid. If we told ourselves that readers should (lower case) infer conformance statements from SHOULD and applicability ones from RECOMMENDED... well, we would be pretty delusional. Also, issuing 2119bis with a subtle difference between the two would create a horrible problem of interpretation for all existing documents (including numerous documents from other SDOs) that explicitly cite 2119. This has ramifications that make my head hurt. Brian
Re: SHOULD and RECOMMENDED
RECOMMENDED is a strong suggestion that the implementation may override at the discretion of the implementer. SHOULD is normative. So the first tells me that I can make up my own mind, the second says that I should give a reason if I don't comply. On Mon, Jun 24, 2013 at 4:18 PM, Yoav Nir y...@checkpoint.com wrote: On Jun 24, 2013, at 10:52 PM, Peter Saint-Andre stpe...@stpeter.im wrote: On 6/24/13 1:47 PM, Michael Thornburgh wrote: my feeling and belief is that RFC 2119 only gives SHOULD and RECOMMENDED the same normative requirement level, but that it does not override or change the distinct meanings of these words in English. sentences using each of these terms have different meanings in English, even when those sentences appear in RFCs. I expect that the subtle differences between these words are lost on non-native speakers, and even most native speakers, of English. I'd be genuinely curious to hear that you think the distinct meanings are. It is RECOMMENDED that implementations send the AUTH_LIFETIME notification at least 4 minutes before the SA is to be deleted, to facilitate the user entering credentials in time. The implementation SHOULD send the AUTH_LIFETIME notification at least 4 minutes before the SA is to be deleted, to facilitate the user entering credentials in time. - What are the subtle differences in meaning between these two sentences? - Would an implementation written by a native speaker be any different depending on which of the above sentences was in the RFC? Yoav -- Website: http://hallambaker.com/
RSOC Appointments
The IAB extends many thanks to the community members that were willing to serve on the RSOC for their ongoing support of the RFC Series and the RFC Series Editor. The IAB especially thanks the current RSOC members for their many contributions. After reviewing the strong list of individuals who offered to serve on the RSOC, the IAB is appointing the following people to serve on the RSOC: Nevil Brownlee, Tony Hansen, Joe Hildebrandt, Bob Hinden, Alexey Melnikov, Bernard Aboba (an IAB member), and Joel Halpern (an IAB member). In addition, Ray Pelletier will continue to serve as liaison from the IAOC to the RSOC. The IAB sincerely thanks all of the people that offered to serve on the RSOC. The IAB particularly thanks the following current RSOC members that will be stepping off the committee during IETF 87 in Berlin: Fred Baker, Ole Jacobsen, John Klensin, and Olaf Kolkman. On behalf of the IAB, Russ Housley IAB Chair
Re: RSOC Appointments
Congratulations, gentlemen. On Jun 24, 2013, at 5:35 PM, IAB Chair iab-ch...@iab.org wrote: Nevil Brownlee, Tony Hansen, Joe Hildebrandt, Bob Hinden, Alexey Melnikov, Bernard Aboba (an IAB member), and Joel Halpern (an IAB member).
Last Call: draft-ivov-grouptextchat-purpose-03.txt (A Group Text Chat Purpose for Conference and Service URIs in the Session Initiation Protocol (SIP) Event Package for Conference State) to Informat
The IESG has received a request from an individual submitter to consider the following document: - 'A Group Text Chat Purpose for Conference and Service URIs in the Session Initiation Protocol (SIP) Event Package for Conference State' draft-ivov-grouptextchat-purpose-03.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-07-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines and registers a value of grouptextchat (Group Text Chat) value for the URI purpose element of SIP's Conference Event Package [RFC4575]. The file can be obtained via http://datatracker.ietf.org/doc/draft-ivov-grouptextchat-purpose/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ivov-grouptextchat-purpose/ballot/ No IPR declarations have been submitted directly on this I-D.
JOSE WG Virtual Interim Meeting, July 15, 2013
The JOSE Working Group will hold a virtual interim meeting on Monday, July 15, 2013 at 10:00 AM PDT. Additional information will be announced on the JOSE WG mailing list: http://www.ietf.org/mail-archive/web/jose/current/maillist.html
RSOC Appointments
The IAB extends many thanks to the community members that were willing to serve on the RSOC for their ongoing support of the RFC Series and the RFC Series Editor. The IAB especially thanks the current RSOC members for their many contributions. After reviewing the strong list of individuals who offered to serve on the RSOC, the IAB is appointing the following people to serve on the RSOC: Nevil Brownlee, Tony Hansen, Joe Hildebrandt, Bob Hinden, Alexey Melnikov, Bernard Aboba (an IAB member), and Joel Halpern (an IAB member). In addition, Ray Pelletier will continue to serve as liaison from the IAOC to the RSOC. The IAB sincerely thanks all of the people that offered to serve on the RSOC. The IAB particularly thanks the following current RSOC members that will be stepping off the committee during IETF 87 in Berlin: Fred Baker, Ole Jacobsen, John Klensin, and Olaf Kolkman. On behalf of the IAB, Russ Housley IAB Chair
