http://permalink.gmane.org/gmane.ietf.bliss hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.bliss/837 <pre>Biggest Fake Conference in Computer Science 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</pre> johnsonhammond2-revL73yDgGBWk0Htik3J/w< at >public.gmane.org 2013-04-27T17:13:58 http://permalink.gmane.org/gmane.ietf.bliss/836 <pre> Dear Martin Huelsemann, Roland Jesske, Denis Alexeitsev, Dale R. Worley: An IPR disclosure that pertains to your RFC entitled "Completion of Calls for the Session Initiation Protocol (SIP)" (RFC6910) was submitted to the IETF Secretariat on 2013-04-22 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2057/). The title of the IPR disclosure is "Research In Motion, Limited's Statement about IPR related to RFC 6910 and draft-ietf-bliss-call-completion-19.""); The IETF Secretariat </pre> IETF Secretariat 2013-04-23T16:29:40 http://permalink.gmane.org/gmane.ietf.bliss/834 <pre>The Basic Level of Interoperability for SIP Services (bliss) working group 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-26T21:27:22 http://permalink.gmane.org/gmane.ietf.bliss/833 <pre> Thank you all for all of your dedication, hard work and most of all, your patience :-) Regards Shida On Feb 26, 2013, at 8:40 AM, Robert Sparks wrote: </pre> Shida Schubert 2013-02-27T20:12:12 http://permalink.gmane.org/gmane.ietf.bliss/832 <pre>Folks - The last of BLISS's documents are in the RFC Editors queue. I don't anticipate a ny AUTH48 issues, and am closing the working group. Thanks for all the work that went into BLISS over the years. RjS </pre> Robert Sparks 2013-02-26T16:40:00 http://permalink.gmane.org/gmane.ietf.bliss/831 <pre>Authors just ignored my suggestion (sent 2012-12-31). So this standard could make interoperability issues. Maybe I'm wrong, but this should be discussed. ----- Original Message ----- From: &lt;internet-drafts-EgrivxUAwEY&lt; at &gt;public.gmane.org&gt; To: &lt;i-d-announce-EgrivxUAwEY&lt; at &gt;public.gmane.org&gt; Cc: &lt;bliss-EgrivxUAwEY&lt; at &gt;public.gmane.org&gt; Sent: Monday, February 11, 2013 8:54 PM Subject: [BLISS] I-D Action: draft-ietf-bliss-call-completion-19.txt </pre> Anton Tveretin 2013-02-15T16:22:14 http://permalink.gmane.org/gmane.ietf.bliss/829 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Basic Level of Interoperability for SIP Services Working Group of the IETF. Title : Call Completion for Session Initiation Protocol (SIP) Author(s) : Dale R. Worley Martin Huelsemann Roland Jesske Denis Alexeitsev Filename : draft-ietf-bliss-call-completion-19.txt Pages : 39 Date : 2013-02-11 Abstract: The call completion feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call. For the realization of a basic solution without queuing, this document references the usage of the dialog event package (RFC 4235) that is described as 'automatic redial' in the SIP Service Examples (RFC 5359). For the realization of a more comprehensive solution with queuing, this do</pre> internet-drafts-EgrivxUAwEY< at >public.gmane.org 2013-02-11T14:54:06 http://permalink.gmane.org/gmane.ietf.bliss/827 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Basic Level of Interoperability for SIP Services Working Group of the IETF. Title : Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) Author(s) : Alan Johnston Mohsen Soroushnejad Venkatesh Venkataramanan Filename : draft-ietf-bliss-shared-appearances-15.txt Pages : 71 Date : 2013-01-16 Abstract: This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP-P</pre> internet-drafts-EgrivxUAwEY< at >public.gmane.org 2013-01-16T21:47:34 http://permalink.gmane.org/gmane.ietf.bliss/826 <pre>Hello All, I think that "busy" state (as oppesed to "free" state) is not something absolute. It means "out of resources" but different calls have different resource requirements. A user might be busy to answer a voice call, but fax could be received automatically. A private network with narrowband link might accept just few video calls, yet might more voice calls. Therefore, we should place enough information, preferrably the entire SDP, into subscription (SUBSCRIBE request). Suggestion: 9.3: add, "The SUBSCRIBE body MUST contain the original session description, to provide information about resource requirements." This could be reproduced in Section 5, somewhat like "There are effectively several queues for calls with different resource requirements". 12.2 Why is it application/call-completion, not text/call-completion? Shouldn't charset appear explicitly? I'm afraid of different encoding problems... This MIME type is also more compact. What is about interoperability with RFC 4235? There is none, but IMO </pre> Anton Tveretin 2012-12-30T22:40:24 http://permalink.gmane.org/gmane.ietf.bliss/824 <pre> Yes, my apologies, I've not been keeping up and got quite rushed and sloppy. And though I'm an author, I haven't been involved in the editing cycles for at least a year (after the my list of technical issues were resolved). What is the best way for me to proceed? Most of my items are really editorial. One other item has technical content, but I think the real issue is that an edit has not been fully applied. The most significant item is that I think the document would be clearer if a summary of behaviors related to the "retain option" was added. Of course, all of these should be decided by the current authors, but what is the proper process at this point? Dale </pre> Dale R. Worley 2012-12-11T16:49:06 http://permalink.gmane.org/gmane.ietf.bliss/823 <pre> Hi Dale; The draft is going through IETF last call not WGLC so any comments you have should be sent to ietf-EgrivxUAwEbhvxM+mQhndA&lt; at &gt;public.gmane.org Detail review is always welcome but you being a co-author of the draft, these comments I think should have been provided sooner to your co-author or included in the ongoing revision that the draft has undergone. Regards Shida On Dec 8, 2012, at 6:28 AM, Dale R. Worley wrote: </pre> Shida Schubert 2012-12-08T15:46:10 http://permalink.gmane.org/gmane.ietf.bliss/822 <pre>Fundamentally, I think the draft is in great shape. The only significant change is that I think a summary of the "retain option" procedures and considerations should be added so the reader can see how it affects the procedures (and how gateways to the PSTN handle "retain"). Only items 2 and 19 have technical content; the remainder are editorial. item 1) headers Can you abbreviate my affiliation on the front page to "Ariadne"? If you are using XML2RFC, you can use the 'abrev' attribute of the &lt;organization&gt; element: &lt;organization abbrev='ISI'&gt; USC/Information Sciences Institute &lt;/organization&gt; item 2) overall The procedures regarding the retain option are scattered throughout the document in a way that makes it difficult to see how it is handled. It seems to me that it would be helpful to add a summary of retain option processing as a section, perhaps at the end of section 4. This allows deleting the last paragraph of section 4.2, which is vague when it stands alone. 4.5 Summary </pre> Dale R. Worley 2012-12-07T21:28:15 http://permalink.gmane.org/gmane.ietf.bliss/821 <pre> The IESG has received a request from the Basic Level of Interoperability for SIP Services WG (bliss) to consider the following document: - 'Call Completion for Session Initiation Protocol (SIP)' &lt;draft-ietf-bliss-call-completion-18.txt&gt; as Proposed Standard 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-EgrivxUAwEY&lt; at &gt;public.gmane.org mailing lists by 2012-12-17. Exceptionally, comments may be sent to iesg-EgrivxUAwEY&lt; at &gt;public.gmane.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The call completion feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call. For the realization of a basic solution without queuing, this document references the usage of the dialog event package (RFC 4235) that is described as 'automatic redial' in the SIP Service E</pre> The IESG 2012-12-03T20:38:32 http://permalink.gmane.org/gmane.ietf.bliss/820 <pre>I have requested IETF Last Call on this version of the document - watch for its announcement soon. RjS On 11/30/12 4:18 AM, Martin.Huelsemann-+tb+GG71Y8CELgA04lAiVw&lt; at &gt;public.gmane.org wrote: </pre> Robert Sparks 2012-12-03T20:06:49 http://permalink.gmane.org/gmane.ietf.bliss/819 <pre> Dear colleagues, due to a boilerplate error the 18 version of the CC draft was uploaded, which changes the boilerplate from 'pre-5378' back to 'trust200902' (as it was until the 16 version). Otherwise the 17 version and the 18 version are identical. Best regards, Martin </pre> Martin.Huelsemann-+tb+GG71Y8CELgA04lAiVw< at >public.gmane.org 2012-11-30T10:18:58 http://permalink.gmane.org/gmane.ietf.bliss/818 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Basic Level of Interoperability for SIP Services Working Group of the IETF. Title : Call Completion for Session Initiation Protocol (SIP) Author(s) : Dale R. Worley Martin Huelsemann Roland Jesske Denis Alexeitsev Filename : draft-ietf-bliss-call-completion-18.txt Pages : 37 Date : 2012-11-30 Abstract: The call completion feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call. For the realization of a basic solution without queuing, this document references the usage of the dialog event package (RFC 4235) that is described as 'automatic redial' in the SIP Service Examples (RFC 5359). For the realization of a more comprehensive solution with queuing, this do</pre> internet-drafts-EgrivxUAwEY< at >public.gmane.org 2012-11-30T10:07:39 http://permalink.gmane.org/gmane.ietf.bliss/817 <pre>Dear colleagues, in this new version of the CC draft the role of the callee's monitor's presence server functionality was made more precise. It was clarified that the the presence status instantiates as soon as it receives a SUBSCRIBE message because without the presence status there would be no CCE's availability state. Further the wording was improved, especially regarding the consistency of CC recall and CC call. Regards, Martin </pre> Martin.Huelsemann-+tb+GG71Y8CELgA04lAiVw< at >public.gmane.org 2012-11-27T15:14:38 http://permalink.gmane.org/gmane.ietf.bliss/816 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Basic Level of Interoperability for SIP Services Working Group of the IETF. Title : Call Completion for Session Initiation Protocol (SIP) Author(s) : Dale R. Worley Martin Huelsemann Roland Jesske Denis Alexeitsev Filename : draft-ietf-bliss-call-completion-17.txt Pages : 37 Date : 2012-11-27 Abstract: The call completion feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call. For the realization of a basic solution without queuing, this document references the usage of the dialog event package (RFC 4235) that is described as 'automatic redial' in the SIP Service Examples (RFC 5359). For the realization of a more comprehensive solution with queuing, this do</pre> internet-drafts-EgrivxUAwEY< at >public.gmane.org 2012-11-27T13:56:24 http://permalink.gmane.org/gmane.ietf.bliss/815 <pre> Hi, a new revision of the CC draft was uploaded, in which the presence server component of the CC monitor was specified a littlebit more exactly. Please check if the functionality is considered appropriately now. Best regards, Martin </pre> Martin.Huelsemann-+tb+GG71Y8CELgA04lAiVw< at >public.gmane.org 2012-09-07T11:36:31 http://permalink.gmane.org/gmane.ietf.bliss/814 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Basic Level of Interoperability for SIP Services Working Group of the IETF. Title : Call Completion for Session Initiation Protocol (SIP) Author(s) : Dale R. Worley Martin Huelsemann Roland Jesske Denis Alexeitsev Filename : draft-ietf-bliss-call-completion-16.txt Pages : 36 Date : 2012-09-07 Abstract: The call completion feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call. For the realization of a basic solution without queuing, this document references the usage of the dialog event package (RFC 4235) that is described as 'automatic redial' in the SIP Service Examples (RFC 5359). For the realization of a more comprehensive solution with queuing , this d</pre> internet-drafts-EgrivxUAwEY< at >public.gmane.org 2012-09-07T11:26:55 http://permalink.gmane.org/gmane.ietf.bliss/813 <pre>That will help - thanks. I'll put the draft into revised-id needed. RjS </pre> Robert Sparks 2012-08-20T17:51:52 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.bliss