headers
johnsonhammond2 | 27 Apr 2013 19:13
Favicon

Biggest Fake Conference in Computer Science

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 
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
IETF Secretariat | 23 Apr 2013 18:29
Picon
Favicon

IPR Disclosure: Research In Motion, Limited's Statement about IPR related to RFC 6910 and draft-ietf-bliss-call-completion-19


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
Permalink | Reply | 0 comments |
headers
IESG Secretary | 26 Feb 2013 22:27
Picon
Favicon

WG Action: Conclusion of Basic Level of Interoperability for SIP Services (bliss)

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.
Permalink | Reply | 0 comments |
headers
Robert Sparks | 26 Feb 2013 17:40
Favicon

Closing BLISS

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
Permalink | Reply | 1 comment |
headers
internet | 11 Feb 2013 15:54
Picon
Favicon

I-D Action: draft-ietf-bliss-call-completion-19.txt


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 document introduces an architecture for implementing these
   features in the Session Initiation Protocol where "call completion"
   implementations associated with the caller's and callee's endpoints
   cooperate to place the caller's request for call completion into a
   queue at the callee's endpoint, and when a caller's request is ready
   to be serviced, re-attempt of the original, failed call is made.
(Continue reading)

Permalink | Reply | 1 comment |
headers
internet | 16 Jan 2013 22:47
Picon
Favicon

I-D Action: draft-ietf-bliss-shared-appearances-15.txt


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-PBX
   offerings and is likely to be implemented on SIP IP telephones and
   SIP feature servers used in a business environment.  This feature
   allows several user agents (UAs) to share a common AOR, learn about
   calls placed and received by other UAs in the group, and pick up or
   join calls within the group.  This document discusses use cases,
   lists requirements and defines extensions to implement this feature.
   This specification updates RFC3261 and RFC4235.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bliss-shared-appearances
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anton Tveretin | 30 Dec 2012 23:40
Picon

Re: draft-ietf-bliss-call-completion-18

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 this
should be explicitly stated somewhere. E.g. in 6.1 or 6.2, "Caller MUST try
this procedure first, and if the "call-completion" event package is
unsupported, it may attempt complete the call as in RFC 4235".

Sorry for being away too long (and cross-posting, if any).

Regards,
Anton Tveretin
Permalink | Reply | 0 comments |
headers
Dale R. Worley | 7 Dec 2012 22:28

Last call comments on draft-ietf-bliss-call-completion-18.

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
<organization> element:

    <organization abbrev='ISI'>
        USC/Information Sciences Institute
    </organization>

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 of retain option procedures
(Continue reading)

Permalink | Reply | 2 comments |
headers
The IESG | 3 Dec 2012 21:38
Picon
Favicon

Last Call: <draft-ietf-bliss-call-completion-18.txt> (Call Completion for Session Initiation Protocol (SIP)) to Proposed Standard


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)'
  <draft-ietf-bliss-call-completion-18.txt> 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@... mailing lists by 2012-12-17. Exceptionally, comments may be
sent to iesg@... 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 Examples
   (RFC 5359).

   For the realization of a more comprehensive solution with queuing,
   this document introduces an architecture for implementing these
   features in the Session Initiation Protocol where "call completion"
   implementations associated with the caller's and callee's endpoints
   cooperate to place the caller's request for call completion into a
   queue at the callee's endpoint, and when a caller's request is ready
   to be serviced, re-attempt of the original, failed call is made.
(Continue reading)

Permalink | Reply | 0 comments |
headers
internet | 30 Nov 2012 11:07
Picon
Favicon

I-D Action: draft-ietf-bliss-call-completion-18.txt


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 document introduces an architecture for implementing these
   features in the Session Initiation Protocol where "call completion"
   implementations associated with the caller's and callee's endpoints
   cooperate to place the caller's request for call completion into a
   queue at the callee's endpoint, and when a caller's request is ready
   to be serviced, re-attempt of the original, failed call is made.
(Continue reading)

Permalink | Reply | 2 comments |
headers
internet | 27 Nov 2012 14:56
Picon
Favicon

I-D Action: draft-ietf-bliss-call-completion-17.txt


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 document introduces an architecture for implementing these
   features in the Session Initiation Protocol where "call completion"
   implementations associated with the caller's and callee's endpoints
   cooperate to place the caller's request for call completion into a
   queue at the callee's endpoint, and when a caller's request is ready
   to be serviced, re-attempt of the original, failed call is made.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane