http://blog.gmane.org/gmane.ietf.simple hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.simple/6567 <pre>We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit t</pre> hammondjohnson< at >hushmail.com 2013-04-27T18:00:16 http://comments.gmane.org/gmane.ietf.simple/6565 <pre>The following errata report has been submitted for RFC4480, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4480&amp;eid=3596 -------------------------------------- Type: Technical Reported by: Ben Campbell &lt;ben&lt; at &gt;nostrum.com&gt; Section: 5.1 Original Text ------------- [There are 8 occurrences of the following element in the schema in section 5.1] &lt;xs:attributeGroup ref="fromUntil"/&gt; Corrected Text -------------- [Each occurrence should be replaced with the following] &lt;xs:attributeGroup ref="dm:fromUntil"/&gt; Notes ----- fromUntil is imported from the presence data model namespace "urn:ietf:params:xml:ns:pidf:data-model". This schema imports that namespace with a prefix of "dm". (see beginning of section 5.1) The prefix was left off of the "fromUntil" entries. Instructions: ------------- This errata is currently posted as "Reported". I</pre> RFC Errata System 2013-04-17T20:08:27 http://comments.gmane.org/gmane.ietf.simple/6564 <pre>All - If you haven't noticed, there's been a discussion on apps-discuss around updating RFC5261, and some errata posted along with that discussion. Erik (copied) has a draft in the works that would address the errata. See &lt;http://tools.ietf.org/html/draft-wilde-xml-patch-04#appendix-A&gt; and &lt;http://www.rfc-editor.org/errata_search.php?rfc=5261&amp;rec_status=2&amp;presentation=records&gt; I recommend putting the errata into Hold for Document Update and work out the details as part of the development of that update. If you are interested, please engage in the discussion on Erik's draft on apps-discuss (or where the ADs guide you). RjS </pre> Robert Sparks 2013-03-22T16:11:34 http://comments.gmane.org/gmane.ietf.simple/6563 <pre> --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________ Simple mailing list Simple&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/simple </pre> Andrew Allen 2013-03-11T14:25:09 http://comments.gmane.org/gmane.ietf.simple/6561 <pre>The SIP for Instant Messaging and Presence Leveraging Extensions (simple) in the Real-time Applications and Infrastructure Area has concluded. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. The mailing list will remain open. </pre> IESG Secretary 2013-02-26T20:57:37 http://comments.gmane.org/gmane.ietf.simple/6559 <pre>Folks - With the last of SIMPLE's documents going into the RFC Editor queue, I'm closing the group. It's been a long road since we demonstrated running code in Pittsburg at IETF 48's IMPP meeting in the summer of 2000. It's been great to be part of helping evolve those early ideas. I'm sure there will be new things to do related to SIMPLE in the future, and anticipate that we'll form new, focused working groups to work through them. DISPATCH will help us find the right structure to get any new work done. Thanks to everyone for the effort you've put into this working group over the years. I'm proud to have been a part of it. RjS </pre> Robert Sparks 2013-02-26T16:50:49 http://comments.gmane.org/gmane.ietf.simple/6558 <pre>Hi everyone, The simple-simple draft has been approved for publication by the IESG. Many thanks to Jonathan for his work on this, and all those who participated in its discussion! Thanks! Ben. </pre> Ben Campbell 2013-02-26T15:04:16 http://comments.gmane.org/gmane.ietf.simple/6557 <pre>The IESG has approved the following document: - 'SIMPLE made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence using the Session Initiation Protocol (SIP)' (draft-ietf-simple-simple-09.txt) as Informational RFC This document is the product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-simple-simple/ Technical Summary The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP). Collectively, these specifications are known as SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions. This document serves as a guide to the SIMPLE suite of specifications. It breaks them up into categories and explains what each is for and how they relate to each other. Working Group Summary This document servers as a roadmap to</pre> The IESG 2013-02-25T22:51:02 http://comments.gmane.org/gmane.ietf.simple/6552 <pre> The following errata report has been submitted for RFC5261, "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5261&amp;eid=3478 -------------------------------------- Type: Technical Reported by: Erik Wilde &lt;dret&lt; at &gt;berkeley.edu&gt; Section: 4.4.3 Original Text ------------- 4.4.3. Replacing a Namespace Declaration URI An example for a replacement of a namespace URI: &lt;replace sel="doc/namespace::pref"&gt;urn:new:xxx&lt;/replace&gt; This will replace the URI value of 'pref' prefixed namespace node with "urn:new:xxx". The parent node of the namespace declaration MUST be the &lt;doc&gt; element, otherwise an error occurs. Corrected Text -------------- 4.4.3. Replacing a Namespace URI An example for a replacement of a namespace URI: &lt;replace sel="doc/namespace::pref"&gt;urn:new:xxx&lt;/replace&gt; This will replace the UR</pre> RFC Errata System 2013-02-07T15:40:41 http://comments.gmane.org/gmane.ietf.simple/6550 <pre> The following errata report has been submitted for RFC5261, "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5261&amp;eid=3477 -------------------------------------- Type: Technical Reported by: Erik Wilde &lt;dret&lt; at &gt;berkeley.edu&gt; Section: 4.2.2 Original Text ------------- In XPath 2.0, a "bar" selector not only matches an unqualified &lt;bar&gt; element, but also matches a qualified &lt;bar&gt; element that is in scope of a default namespace declaration. In contrast, in this specification, a selector without a prefix only matches one element, and it may match an element with or without a prefix but only if the namespace it's qualified with (or none) is an exact match. Corrected Text -------------- In XPath 2.0, a "bar" selector matches elements that have the URI of the "default element/type namespace", which is part of an XPath's stat</pre> RFC Errata System 2013-02-05T10:25:14 http://comments.gmane.org/gmane.ietf.simple/6549 <pre>Hello, By implementing the draft specifications for SIMPLE/MSRP to XMPP and MSRP-switch to MUC gateway we discovered several issues that we needed to tackle differently or were not addressed at all at the moment of their writing. The drafts I am referring to are: http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-01 http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-presence-02.html http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-im-01.html http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-chat-03.html http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-groupchat-01.html As there are many comments, we made a web page to summarize them as best as we could. http://sylkserver.ag-projects.com/projects/sylkserver/wiki/XMPP-Interop The software implementing these drafts is now available in the public domain. I hope this feedback can be used to continue and finalize the standardization works started in those drafts. I am not sure which WG is the best place for this, so I m</pre> Adrian Georgescu 2013-02-04T13:08:11 http://comments.gmane.org/gmane.ietf.simple/6548 <pre> The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'SIMPLE made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence using the Session Initiation Protocol (SIP)' &lt;draft-ietf-simple-simple-08.txt&gt; 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 ietf&lt; at &gt;ietf.org mailing lists by 2013-02-14. Exceptionally, comments may be sent to iesg&lt; at &gt;ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP). Collectively, these specifications are known as SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions. This document serves as a guide to the SIMPLE suite of s</pre> The IESG 2013-01-31T22:04:50 http://comments.gmane.org/gmane.ietf.simple/6547 <pre>Hi, The SIMPLE working group requests publication of draft-ietf-simple-simple-08. The proto writeup follows: ------------------------------------------------------------ The RFC is intended to be informational. The title header page indicates informational. Technical Summary The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP). Collectively, these specifications are known as SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions. This document serves as a guide to the SIMPLE suite of specifications. It breaks them up into categories and explains what each is for and how they relate to each other. Working Group Summary This document servers as a roadmap to the SIMPLE specifications. It introduces no technical content beyond the summaries of those specifications. While some of the referenced specifications had some degree of controversy, this draft was not controversial in itself. Document Quality. This docume</pre> Ben Campbell 2013-01-31T03:56:21 http://comments.gmane.org/gmane.ietf.simple/6542 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIMPLE made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence using the Session Initiation Protocol (SIP) Author(s) : Jonathan Rosenberg Filename : draft-ietf-simple-simple-08.txt Pages : 15 Date : 2013-01-28 Abstract: The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP). Collectively, these specifications are known as SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions. This document serves as a guide to the SIMPLE suite of specifications. It breaks them up into categories and explains what each is for and how they relate to each other. The IETF datatracker status page for this draft is: https://datatrac</pre> internet-drafts< at >ietf.org 2013-01-29T00:44:53 http://comments.gmane.org/gmane.ietf.simple/6540 <pre> The following errata report has been submitted for RFC5261, "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5261&amp;eid=3465 -------------------------------------- Type: Technical Reported by: Erik Wilde &lt;dret&lt; at &gt;berkeley.edu&gt; Section: 4.2.3 Original Text ------------- Lastly, if the above two rules still don't apply, first all in-scope namespace prefixes of the evaluation context node are arranged alphabetically in an ascending order. Corrected Text -------------- n/a Notes ----- It is not entirely clear what "arranged alphabetically" refers to in this section. Sorting can be done in a variety of ways, and while many environment may have standard sort orders, not all are the same and for this standard to be implement consistently it's important to clearly state what sort order the above sentence is referring to. The su</pre> RFC Errata System 2013-01-18T09:27:22 http://comments.gmane.org/gmane.ietf.simple/6536 <pre>Hello Group, In regards to TLS over MSRP. Scenario: There are two sessions between UE-A and UE-B, in which B chose to be active endpoint in both the sessions (a=setup:active), of which one session is over TLS and another is over TCP. Two incoming connection requests will arrive at A. What is the best approach for A to distinguish TLS request from TCP? In case of SIP its easy as there are separate ports for TCP and TLS. so the connection request will be identified based on the port upon which the request arrived. But for MSRP rfc 4975 doesn't recommend a different port, so both requests could arrive at same 2855 port. Thanks &amp; Regards, Prasun Bheri _______________________________________________ Simple mailing list Simple&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/simple </pre> Prasun Bheri 2013-01-17T08:15:52 http://comments.gmane.org/gmane.ietf.simple/6535 <pre> The following errata report has been submitted for RFC5261, "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5261&amp;eid=3458 -------------------------------------- Type: Technical Reported by: Erik Wilde &lt;dret&lt; at &gt;berkeley.edu&gt; Section: 8 Original Text ------------- &lt;!ENTITY id "id\(('&amp;ncname;')?\)|id\((&amp;quot;&amp;ncname;&amp;quot;)?\)"&gt; Corrected Text -------------- &lt;!ENTITY id "id\('&amp;ncname;'\)|id\(&amp;quot;&amp;ncname;&amp;quot;\)"&gt; Notes ----- The regex in the XSD suggests that "id()" would be a valid selector for a patch, but it would not make sense to specify such a selector since it never would select a node (there's no identifier to locate in the document). This means that while "id()" is a valid XPath expression, it should not be allowed as a selector expression within an XML patch document. Instructions: ------------- Th</pre> RFC Errata System 2013-01-16T14:13:51 http://comments.gmane.org/gmane.ietf.simple/6519 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Multi-party Chat Using the Message Session Relay Protocol (MSRP) Author(s) : Aki Niemi Miguel A. Garcia-Martin Geir A. Sandbakken Filename : draft-ietf-simple-chat-17.txt Pages : 42 Date : 2012-11-17 Abstract: The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-simple-chat There's also a htmlized version ava</pre> internet-drafts< at >ietf.org 2012-11-17T16:06:11 http://comments.gmane.org/gmane.ietf.simple/6516 <pre>Hello, I have been working on this draft (http://tools.ietf.org/html/draft-pd-msrp-websocket-01) to enable MSRP to be used over WebSocket transport. The latest Kamailio code-base in Git contains an MSRP over WebSocket server implementation. Can anyone advise as to whether there is interest in moving this draft forward, and if so, what the correct process for doing so is? Regards, Peter Dunkley </pre> Peter Dunkley 2012-11-06T12:50:40 http://comments.gmane.org/gmane.ietf.simple/6490 <pre>(as SIMPLE chair) Hi Everyone, We've recently had several very interesting thread about the interoperability issues in SIMPLE and what could be done to improve them. I'd like to see those discussions make progress. But please keep in mind that the work group is very close to completion on all it's milestones. (For the purpose of this thread, lets please ignore the question about whether that means "successful" completion). SIMPLE will almost certainly close in the near future. That doesn't mean new work can't happen. It does mean that any such work will need to go through the normal RAI processes for substantially new work. Normally that means taking a proposal to DISPATCH. Success in DISPATCH will require the interested parties to (roughly) agree on the nature of the problem to be solved, and the scope of the work needed to do so. A problem statement in the form of an Internet-Draft would be extremely helpful. I suggest that the interested parties take the following concrete actions: 1) Work toward a </pre> Ben Campbell 2012-11-01T21:47:24 http://comments.gmane.org/gmane.ietf.simple/6449 <pre>Simple friends ;-) I am surprised to see very few advocates for the current set of RFCs. It seems like everyone on this list agrees that SIMPLE failed to deliver interoperability in the current form, that the specifications leave too much to implementations and that there are undefined areas that needs to be defined in an IETF document (which may currently be specified elsewhere). I see that the discussions diverge on a short-term and a long term plan. The short-term plan is to focus on the existing set of recommendations in RFCs and try to find out which implementation guidelines and maybe extra set of documents that are needed to get a baseline interoperability in handling of a simple buddy list, presence involving multiple devices and presence authorization. There seems to be an agreement that MSRP based chat works. The long-term plan is to spend time on developing something that would be much easier to implement, not require 18 (or more) subscriptions with states and be easier to interoperate with X</pre> Olle E. Johansson 2012-10-24T17:00:41 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.simple