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://permalink.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 the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. _______________________________________________ Simple mailing list Simple&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/simple </pre> hammondjohnson< at >hushmail.com 2013-04-27T18:00:16 http://permalink.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". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4480 (draft-ietf-simple-rpid-10) -------------------------------------- Title : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) Publication Date : July 2006 Author(s) : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg Category : PROPOSED STANDARD Source : SIP for Instant Messaging and Presence Leveraging Extensions Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG </pre> RFC Errata System 2013-04-17T20:08:27 http://permalink.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://permalink.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://permalink.gmane.org/gmane.ietf.simple/6562 <pre> 26 feb 2013 kl. 18:17 skrev Ben Campbell &lt;ben&lt; at &gt;nostrum.com&gt;: Thank you both! Yes, let's try to focus on the interop issues in DISPATCH and see where that takes us. /Olle </pre> Olle E. Johansson 2013-02-28T08:00:54 http://permalink.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://permalink.gmane.org/gmane.ietf.simple/6560 <pre>(As chair, for the last time) Hi Everyone, As Robert indicated, it's been a long, strange trip from there to here. I'd like to personally thank all of our many draft editors, contributors, and discussion participants over the last 13 years. Thanks also go to Hisham and Robert for their chair roles at various times along the way. SIMPLE is still a living protocol suite. Please do not hesitate to bring up issues and new ideas--that's what the DISPATCH process is all about. Thanks! Ben. On Feb 26, 2013, at 10:50 AM, Robert Sparks &lt;rjsparks&lt; at &gt;nostrum.com&gt; wrote: </pre> Ben Campbell 2013-02-26T17:17:03 http://permalink.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://permalink.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://permalink.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 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 document is a roadmap to other specifications, and therefore has no directly implementable content. The document has undergone normal working group review. There have been no specialized expert reviews, and the shepherd does not believe such reviews are needed, other than those normal for all documents (e.g. Gen-ART). Personnel The document shepherd for this document is Ben Campbell. The responsible Area Director is Robert Sparks. </pre> The IESG 2013-02-25T22:51:02 http://permalink.gmane.org/gmane.ietf.simple/6554 <pre>Olle, I agree with Ben's assessment above. When we started this draft, we decided on a fairly hard definition around scope of what is included, and what is not. We purposely are not including the many SIP extensions that apply in general to SIP, including presence. As such, I do not think we should include rfc6072 or 5922. Similarly I dont think a section on xcap (useful as it might be) belongs here. I look forward to seeing your draft ;) Thanks, Jonathan R. On Wed, Jan 30, 2013 at 1:56 PM, Ben Campbell &lt;ben&lt; at &gt;nostrum.com&gt; wrote: </pre> Jonathan Rosenberg 2013-02-16T12:37:19 http://permalink.gmane.org/gmane.ietf.simple/6553 <pre>hello bjoern. thanks a lot for the quick feedback! On 2013-02-05 12:16 , Bjoern Hoehrmann wrote: yes, you're right that this is not necessarily a correct conclusion. it would be really great to figure this out, though, because the convenience of being able to use a standard implementation cannot be overstated. i am writing http://tools.ietf.org/html/draft-wilde-xml-patch-01 which is intended to be based on RFC 5261 (which is why am reading it very closely now), and it would be great to have an implementation hints section (i am currently writing one) that would clearly tell implementers what they can and cannot use. it's bad enough that you cannot use a standard XPath 1.0 implementation; it would be great if at least XPath 2.0 would be usable. any insights would be greatly appreciated, i think i have to look closer into the XPath subset of the RFC and see whether that contains anything where XPath 1.0 and 2.0 differ. in the interest of readability, http://tools.ietf.org/html/draft-wilde-xml-patch-01#appendix-B now has an ABNF for the grammar in RFC 5261, where it's only defined in the XSD. i have also filed an erratum about the grammar, because it allows "id()", which never selects anything: http://www.rfc-editor.org/errata_search.php?rfc=5261&amp;eid=3458 thanks again and cheers, dret. </pre> Erik Wilde 2013-02-05T13:17:34 http://permalink.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 URI of the namespace associated with the 'pref' prefix with "urn:new:xxx". The parent node of the namespace declaration MUST be the &lt;doc&gt; element, otherwise an error occurs. Replacing the namespace at the element where it is declared MUST also change all namespace nodes derived from this declaration in descendant elements. Notes ----- The spec uses the terms "namespace declaration" and "namespace" almost interchangeably, which is incorrect. It is impossible to select (and thus patch) *namespace declarations* using XPath. When selecting and replacing a *namespace*, then it should be taken into account that the *namespace declaration* very likely has resulted in numerous namespace nodes, attached to child elements of the element where the namespace was declared. It is likely that the spec intended to specify a "recursive replace" of the resulting namespace nodes of a namespace declaration, and this is what the corrected text suggests. The original text is mixing terminology, hard to read, and ambiguous in its meaning. If the spec text instead tried to specify that really only this one namespace node should be changed, then this can lead to rather strange effects in the resulting document, since the XPath tree now has "orphan" namespace nodes, which then need to be serialized and namespace declarations in locations where previously no namespace declarations occurred. One way or the other, this ambiguity needs to be clarified to make the spec easier to read and implement. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5261 (draft-ietf-simple-xml-patch-ops-04) -------------------------------------- Title : An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors Publication Date : September 2008 Author(s) : J. Urpalainen Category : PROPOSED STANDARD Source : SIP for Instant Messaging and Presence Leveraging Extensions Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG </pre> RFC Errata System 2013-02-07T15:40:41 http://permalink.gmane.org/gmane.ietf.simple/6551 <pre> Indeed, see &lt;http://www.w3.org/TR/xpath20/#node-tests&gt;, 3rd paragraph. (I do note that this is not the only difference between XPath 1.0 and XPath 2.0, so the conclusion that then XPath 2.0 can be used to evalu- ate XML Patch selectors is not necessarily correct, especially if it cannot be assumed that defaults like "Default element/type namespace" cannot be assumed to be chosen to maximise compatibility. But that is out of scope of the Original Text this item is concerned with.) </pre> Bjoern Hoehrmann 2013-02-05T11:16:58 http://permalink.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 static context. By setting this URI to the default namespace of the diff document (or leave it empty, if there is none), XPath 2.0's behavior matches the requirements of the previous section. Notes ----- The original text is not easy to understand, but seems to assume that an unprefixed name in XPath 2.0 matches both unprefixed names, and prefixed ones that have the same namespace than the default namespace of the XPath static context. This is not the case: Matching depends on how the "default element/type namespace" of the XPath static context is defined, and then matches either namespace-less elements, or those in the "default element/type namespace", but never both. This context, however, is defined by the XPath itself, not by the document. Thus, it can be set externally and could be set to the diff document's default namespace (if there is one). In that case, XPath 2.0 can be used to evaluate XML Patch selectors. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5261 (draft-ietf-simple-xml-patch-ops-04) -------------------------------------- Title : An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors Publication Date : September 2008 Author(s) : J. Urpalainen Category : PROPOSED STANDARD Source : SIP for Instant Messaging and Presence Leveraging Extensions Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG </pre> RFC Errata System 2013-02-05T10:25:14 http://permalink.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 mailed all three I am aware of. Regards, Adrian </pre> Adrian Georgescu 2013-02-04T13:08:11 http://permalink.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 specifications. It breaks them up into categories and explains what each is for and how they relate to each other. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-simple-simple/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-simple-simple/ballot/ No IPR declarations have been submitted directly on this I-D. </pre> The IESG 2013-01-31T22:04:50 http://permalink.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 document is a roadmap to other specifications, and therefore has no directly implementable content. The document has undergone normal working group review. There have been no specialized expert reviews, and the shepherd does not believe such reviews are needed, other than those normal for all documents (e.g. Gen-ART). Personnel The document shepherd for this document is Ben Campbell. The responsible Area Director is Robert Sparks. The document shepherd reviewed this document for content, structure, and nits. There is a single outstanding nit (an informative reference to RFC 3265 which has been obsoleted by RFC 6665). We plan to update that reference along with any updates indicated by the IETF last call results prior to final publication. The shepherd believes the document to be otherwise ready for publication. The document shepherd has no concerns about the depth or breadth of the reviews. The shepherd believes all aspects of this document has been sufficiently reviewed. There have been no specialized expert reviews, and the shepherd does not believe such reviews are needed. The shepherd has no concerns about the document. It seems fairly non-controversial. Author confirmation is pending at the time of submission. However, since the document is comprised of summaries of and references to other documents, the need for IPR disclosures seems unlikely. There have been no IPR disclosures referencing this document. As an roadmap to other SIMPLE specifications, this document originally had wide working group consensus. However, very little discussion has occurred since then. The shepherd believes that this is to be expected given the nature of the document as a roadmap to other work. No significant objections have been raised to this document. No one has threatened an appeal or otherwise indicated extreme discontent. The Document Shepherd believes that the document contains all needed information, and that all nits are covered except for the obsolete reference mentioned in section (3). The document has not gone through any formal review beyond routine working group reviews. The shepherd does not believe any such reviews are needed. All references are identified as informative. There are no normative references. There is an informative reference to draft-ietf-simple-chat, which has been approved for publication by the IESG. There are no normative references. This document does not effect the status of any existing RFC. The shepherd has extensively reviewed the IANA considerations, and determined that the draft makes no request of IANA, nor are any such requests appropriate. (The shepherd further notes that the IANA considerations consist entirely of the word "None.") The document does not establish any new registries. (Really, it says "None.") The draft contains no formal language requiring validation. </pre> Ben Campbell 2013-01-31T03:56:21 http://permalink.gmane.org/gmane.ietf.simple/6546 <pre>(as chair) Robert has asked us to progress this as soon as possible. I plan to go ahead and do that for the existing version. That does _not_ mean we should ignore feedback, nor should we shut down this discussion. We will just treat any further comments and discussion as if they were IETF Last Call comments. Thanks! Ben. On Jan 30, 2013, at 1:49 AM, Olle E Johanson &lt;oej&lt; at &gt;edvina.net&gt; wrote: </pre> Ben Campbell 2013-01-30T18:56:07 http://permalink.gmane.org/gmane.ietf.simple/6545 <pre>(As individual) On Jan 30, 2013, at 1:49 AM, Olle E Johanson &lt;oej&lt; at &gt;edvina.net&gt; wrote: My personal opinion is that general SIP mechanisms are out of scope for this draft. Otherwise, we could pull in most of the body of work of SIP. SIP-events is an exception, since it is core to all of the presence work. At most,we might considert a paragraph mentioning that many SIP related mechanisms can apply to SIMPLE just like any other SIP usage, perhaps with a ref to the hitchhiker's guide. I agree that this wouldn't add value to this doc. Also, I think that's important enough of a concern to warrant its own draft :-) </pre> Ben Campbell 2013-01-30T14:33:44 http://permalink.gmane.org/gmane.ietf.simple/6544 <pre> 29 jan 2013 kl. 15:17 skrev Ben Campbell &lt;ben&lt; at &gt;nostrum.com&gt;: Ok, I know I had years to make a comment, but anyway :-) I would like to see references to the SIP domain certificate specification, as it plays a role for implementors, as well as the SIP certificate management service. These should be important for anyone building SIMPLE implementations and adds some missing pieces in the SIMPLE specs. - RFC 6072 Certificate Maangement Service for Session Initiation Protocol http://tools.ietf.org/html/rfc6072 - RFC 5922 Domain Certificates in the Session Initiation Protocol http://tools.ietf.org/html/rfc5922 Maybe we could add a clarification for newbies that "The SIP subscribe/notify mechanism is not only used in SIMPLE, but also in other event packages outside of the scope of this document." I could possibly also add a section about the missing interoperability in presence/XCAP implementations but that propably won't help this particular document that I find has a lot of value. See you all at SIPit 30! Only a few days of registration open - so please hurry to http://www.sipit.net and register! /O </pre> Olle E Johanson 2013-01-30T07:49:14 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.simple