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 
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

URI scheme registration request - dchub

_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review

PKCS#11 URI registration request review

	hello,

	in accordance with section "5.2. Registration Procedures" of RFC 
4395 "Guidelines and Registration Procedures for New URI Schemes", I 
respectfully request a review for our planned permanent registration 
request of the PKCS#11 URI as specified in the following I-D:

	http://tools.ietf.org/html/draft-pechanec-pkcs11uri-08

	the registration template is attached.

	best regards, Jan Pechanec

-- 
Jan Pechanec
http://blogs.oracle.com/janp

#
# Registration template for PKCS#11 URI.
#

According to RFC 4395, Section "5.2. Registration Procedures", and Section "5.4.
URI Scheme Registration Template", this document specifies the registration
template for the PKCS#11 URI registration request.

Template author: Jan Pechanec <jan.pechanec <at> oracle.com>

The template references sections in the following I-D:

  http://tools.ietf.org/html/draft-pechanec-pkcs11uri-08


#
# Template starts here.
#

URI scheme name: pkcs11 (section "3.1.  PKCS#11 URI Scheme Name")

URI scheme status: permanent (section "3.2.  PKCS#11 URI Scheme Status")

URI scheme syntax: Section "3.3.  PKCS#11 URI Scheme Syntax"

URI scheme semantics: Section "1.  Introduction"

Encoding considerations: Section "3.3.  PKCS#11 URI Scheme Syntax"

Applications/protocols that use this URI scheme name: Section "1.  Introduction"

More specifically, list of applications that already use PKCS#11 URI according
to the existing drafts follows. The list may not be complete.

GnuTLS
	- www.gnutls.org

	- in gnutls_pkcs11_obj_info_t structure
	- parser is in pkcs11_get_info())
Gnome
	- in libgck library used by gnome-keyring since version 3.3.5
	- http://developer.gnome.org/gck/3.6/gck-PKCS11-URIs.html

p11-kit
	- http://cgit.freedesktop.org/p11-glue/p11-kit

	- parsing function is p11_kit_uri_parse()
OpenSC
	- http://www.opensc-project.org

	- uses PKCS#11 URIs via p11-kit
Solaris 11
	- ZFS crypto
		- zfs_encrypt(1M) manual page
	- SunSSH for X.509 based authentication
		- sshd(1M) manual page (section "Using X.509 Certificates as
		  Host Keys and User Identities")

Interoperability considerations: N/A

Security considerations: Section "6.  Security Considerations"

Contact: Jan Pechanec, Darren J. Moffat. Section "Authors' Addresses"

Author/Change Controller: N/A (permanent registration requested, not
provisional)

References: Section "7.  References"

_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review

request for review: 'acct' scheme

This message constitutes a request for review of the proposed 'acct' URI
scheme, specified in draft-ietf-appsawg-acct-uri-02. The completed
registration template follows (copied from the IANA Considerations of
the aforementioned I-D).

Peter

###

4. IANA Considerations

   In accordance with the guidelines and registration procedures for new
   URI schemes [RFC4395], this section provides the information needed
   to register the 'acct' URI scheme.

4.1. URI Scheme Name

   acct

4.2. Status

   permanent

4.3. URI Scheme Syntax

   The 'acct' URI syntax is defined here in Augmented Backus-Naur Form
   (ABNF) [RFC5234], borrowing the 'host', 'pct-encoded', 'sub-delims',
   'unreserved' rules from [RFC3986]:

   acctURI      =  "acct" ":" userpart " <at> " host
   userpart     =  1*( unreserved / pct-encoded / sub-delims )

4.4. URI Scheme Semantics

   The 'acct' URI scheme identifies accounts hosted at service
   providers.  It is used only for identification, not interaction.  A
   protocol that employs the 'acct' URI scheme is responsible for
   specifying how an 'acct' URI is dereferenced in the context of that
   protocol.  There is no media type associated with the 'acct' URI
   scheme.

4.5. Encoding Considerations

   The 'acct' URI scheme allows any character from the Unicode
   repertoire [UNICODE] encoded as UTF-8 [RFC3629] and then percent-
   encoded into valid ASCII [RFC20] as specified in [RFC3986].  Note
   that domain labels need to be encoded as A-labels (see [RFC5890]) in
   order to support internationalized domain names (IDNs).

4.6. Applications/Protocols That Use This URI Scheme Name

   At the time of this writing, only the WebFinger protocol uses the
   'acct' URI scheme.  However, use is not restricted to the WebFinger
   protocol, and the scheme might be considered for use in other
   protocols, such as Simple Web Discovery.

4.7. Interoperability Considerations

   There are no known interoperability concerns related to use of the
   'acct' URI scheme.

4.8. Security Considerations

   See Section 5 of RFCXXXX.  [Note to RFC Editor: please replace XXXX
   with the number issued to this document.]

4.9. Contact

   Peter Saint-Andre, psaintan <at> cisco.com

4.10. Author/Change Controller

   This scheme is registered under the IETF tree.  As such, the IETF
   maintains change control.

4.11. References

   None.

###

Fwd: TURN/STUN URI Drafts

URI Reviewers,

As a component of the RTCWEB work we are trying to define and register the TURN and STUN URI schemes. As part of
that work these drafts are now normatively referenced by the W3C (http://www.w3.org/TR/webrtc/ and
http://dev.w3.org/2011/webrtc/editor/webrtc.html) and have already been implemented in Google
(Chrome) in their current STUN/TURN server configuration code and is in the process of being implemented
by Mozilla (Firefox)]. I have left the below thread to provide a bit of context on these drafts. These
drafts can be found here:

TURN URI:
http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uris 

STUN URI:
http://tools.ietf.org/html/draft-nandakumar-rtcweb-stun-uri

The TURN URI scheme was first proposed several years ago and has already been through uri-review back in
late 2009 (https://www.ietf.org/mail-archive/web/uri-review/current/msg01063.html). The
current TURN URI proposal is a result of that discussion.  The STUN URI came about more recently but is
intended to be complementary.

We kindly request that you review the proposed URI schemes.

We look forward to your feedback.

Thanks!

Gonzalo

Begin forwarded message:

> From: Pete Resnick <presnick <at> qti.qualcomm.com>
> Subject: Re: TURN/STUN URI Drafts
> Date: January 3, 2013 11:23:28 AM EST
> To: Marc Petit-Huguenin <petithug <at> acm.org>
> Cc: Gonzalo Camarillo <Gonzalo.Camarillo <at> ericsson.com>, Gonzalo Salgueiro <gsalguei <at> cisco.com>,
"Suhas Nandakumar (snandaku)" <snandaku <at> cisco.com>, Paul Jones <paulej <at> packetizer.com>, Cullen
Jennings <fluffy <at> cisco.com>, Barry Leiba <barryleiba <at> computer.org>
> 
> Happy New Year to you as well.
> 
> You should probably first send these drafts to uri-review <at> ietf.org to see if there everyone is OK.
Assuming that's true (from a quick peek, there's nothing obviously horrible), either Barry or I can AD
sponsor the documents. But I'd like to hear what Graham and the other uri-review folks have to say.
> 
> Cheers,
> 
> pr
> 
> On 1/2/13 11:23 AM, Marc Petit-Huguenin wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>> 
>> Happy New Year to everybody.
>> 
>> I did not see any progress on this topic since this email.  Would it be
>> possible to have a status update on what is blocking this, and how I can help
>> to make this happen?
>> 
>> Thanks.
>> 
>> On 11/05/2012 11:50 AM, Gonzalo Camarillo wrote:
>>   
>>> Hi Pete,
>>> 
>>> so, per our conversation in the welcome reception, please have a look at
>>> the email below and let the authors know how to proceed (i.e., whether or
>>> not they need a standards track RFC).
>>> 
>>> If I need to take care of something (e.g., AD sponsoring a draft), let me
>>> know as well.
>>> 
>>> Cheers,
>>> 
>>> Gonzalo
>>> 
>>> On 04/11/2012 11:44 PM, Gonzalo Salgueiro wrote:
>>>     
>>>> Gonzalo/Pete -
>>>> 
>>>> As requested, this is the follow up email regarding the TURN/STUN URI
>>>> drafts that require AD-sponsoring:
>>>> 
>>>> TURN URI:
>>>> http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uris STUN URI:
>>>> http://tools.ietf.org/html/draft-nandakumar-rtcweb-stun-uri
>>>> 
>>>> To provide a bit of context this all began with Marc Petit-Hugenin six
>>>> years ago attempting to standardize the TURN URI scheme in the BEHAVE WG.
>>>> At that time there were no applications of this on the Internet, so it
>>>> was deemed premature and remained a draft. Recently, the need for a
>>>> standard URI scheme for TURN and STUN has arisen in the context of
>>>> RTCWeb.  Cullen (on Cc:) pointed this out and under his guidance we
>>>> produced the drafts referenced above. These drafts are now normatively
>>>> referenced by the W3C (http://www.w3.org/TR/webrtc/ and
>>>> http://dev.w3.org/2011/webrtc/editor/webrtc.html) and have already been
>>>> implemented in Google (Chrome) in their current STUN/TURN server
>>>> configuration code and is in the process of being implemented by Mozilla
>>>> (Firefox).
>>>> 
>>>> Over the years the TURN draft (and much later the STUN draft) have
>>>> received feedback from both the BEHAVE and RTCWEB WGs and we feel they
>>>> are nearing completion. We certainly would welcome any additional
>>>> feedback but more practically in the context being progressed within the
>>>> IETF to RFC status.  Please let us know how we can facilitate this and if
>>>> there is anything we can do make this as expeditious and painless for you
>>>> guys as possible.
>>>> 
>>>> Sincere thanks for all your help and guidance.
>>>> 
>>>> Cheers,
>>>> 
>>>> Gonzalo
>>>> 
>>>>       
>>>     
>> 
>> - -- Marc Petit-Huguenin
>> Email: marc <at> petit-huguenin.org
>> Blog: http://blog.marc.petit-huguenin.org
>> Profile: http://www.linkedin.com/in/petithug
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.12 (GNU/Linux)
>> 
>> iQIcBAEBCAAGBQJQ5G0mAAoJECnERZXWan7EP6IP/0eylpav+SHT3DzVrZ6IvdYr
>> zkBSb+8osVPHYXkC8BXHBE5cT/9SKYvfLRMMMX4X92ILIGpeVeWF9SDMNuxGAGsG
>> QIE3gWZErhrF3m3JBkbHxG+un6IW0DPlKBGj4/ZL3+eVueMQVL+lxIPyGorgwJEi
>> YAjvxuTzmrT3NjujC2qPqlPqphdlq/bJK89sSCsH7pY68THZUIcWTSIhzq446NFB
>> B+utwPoPI2Rubyx9AR6uMWSPAjB7x5uGzE2DP8B5ZU55qq4iAGPup6qFGHOWHvXE
>> q9WoqX0zXjNFNYEIC/DLYZI99WCPN0Ouj5GYtZklHK7cKcngknNNw5T8tz6jPBj9
>> kiQbC2YjoXVZ9Gk3B/XAdk4BBDz6jDzo+q1N0WkgCIwGITn6xg9tOIVei6CwgC2i
>> mDXT6HwVgXHjSwXYNBkRTuTmUZlJmd3A5bl8wdx3XVe0dtcTEkJAdk6F/ScBFXz1
>> Ah2XB8OdqaCd5YyBbdYXMEcDmztsS9THdVhSd3IlHmAtGtj0nYyvkLuKdKsBfrCM
>> bKkfuvpjLOFk8kmkEu0zgtsGA9JA2ROkk0nKeMoJhBkSAJY4Y8qMSxWoJbegyJ5C
>> k8TePgYMGO8aROFI6+iC0+ekcinc3CPeen/MnneNH1t9+Zvk00/X9t8bCSizLLFt
>> mDdyOAv6Stfiax/sMFHa
>> =gCwm
>> -----END PGP SIGNATURE-----
>>   
> 
> -- 
> Pete Resnick<http://www.qualcomm.com/~presnick/>
> Qualcomm Technologies, Inc. - +1 (858)651-4478
> 

dvb: URI scheme

Dear uri-review,

Some time ago, I published a rather 'light' I-D which documents the dvb: URI scheme, as used by cable,
satellite and terrestrial TVs, PVRs and set-top boxes which adhere to the DVB[1][2] standard (and some
more besides).

Since then, I've collaborated with Alexander Adolf, who chairs the Generic Data Broadcasting & Service
Information Protocols working group[3] of the DVB Project, to flesh out the draft into something which is
a little more useful without referring back to the canonical reference for the scheme, ETSI TS 102 851.

As we are both relatively satisfied that the draft can be considered stable, we are looking to move from
provisional to permanent registration of the scheme at IANA, and publication of the draft as an RFC.

As a step towards that, we're putting out this call for comments here.

It's probably worth stressing that the intent of the I-D is to document (and codify within the Internet,
rather than broadcasting, community) the existing behaviour and design of the scheme; as retrospective
documentation goes, this one's covering a scheme which is pretty well-baked. That said, I'm sure
Alexander will be more than happy to feed back any constructive criticism of the scheme itself via the DVB
TM-GBS group to help shape future editions of the standards.

Please do CC: Alexander and me in any replies as we're not subscribed to the list.

Many thanks,

Mo.

[1] http://www.dvb.org
[2] http://en.wikipedia.org/wiki/Digital_Video_Broadcasting
[3] http://www.dvb.org/groups_modules/technical_module/tmgbs/index.xml?groupID=5

--
Mo McRoberts - Technical Lead - The Space
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
Zone 1.08, BBC Scotland, Pacific Quay, Glasgow, G51 1DA
Project Office: Room 7083, BBC Television Centre, London W12 7RJ

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

[about] about:invalid

Hi,

On yesterday's telcon[1], the CSS WG resolved to mint about:invalid,
which is now defined in CSS3 Values and Units as "a URI [that points] to
a non-existent document with a generic error condition."[2] I don't
think "The 'about' URI scheme" needs to change as a result.

Thanks,
Ted

1. http://lists.w3.org/Archives/Public/www-style/2012Jul/0109.html
2. http://dev.w3.org/csswg/css3-values/#attr-notation

The "acct" URI scheme

URI Reviewers,

We are progressing work in the IETF on WebFinger.  As a component of that
work, we have defined the “acct” URI scheme that we would like to register. 
The “acct” URI scheme was first proposed several years ago in the Internet
community and already adopted in some implementations (including Google+),
etc.  The specification attempts to formalize and finalize the WebFinger
specification, including the “acct” URI scheme.

The URI scheme registration template  can be found in Section 12.1 of this
draft:
http://tools.ietf.org/id/draft-jones-appsawg-webfinger-06.txt

We kindly request that you review the proposed URI scheme.

We look forward to your feedback.

Thanks!
Paul

Re: In WG last call review of URI Schemes rtsp, rtsps and rtspu

_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review

Re: the "ni:" URI scheme soon to "last call" in IETF -- security concern

Hi Stephen,

This looks like a very nice piece of work.  However, I think there is an
additional security concern that should be addressed, as described
below.  (You can ignore the first three paragraphs of the message below,
as they address a different topic.)

Thanks,
David

-------- Forwarded Message --------
From: David Booth <david <at> dbooth.org>
To: Larry Masinter <masinter <at> adobe.com>
Cc: www-tag <at> w3.org <www-tag <at> w3.org>
Subject: Re: the "ni:" URI scheme soon to "last call" in IETF,
httpRange-14 and security
Date: Wed, 02 May 2012 11:29:24 -0400

On Wed, 2012-05-02 at 11:19 -0400, David Booth wrote:
> BTW, I've been meaning to mention that this "Named Information" (NI)
> mechanism *is* actually relevant to the httpRange-14 discussion, because
> it addresses the need for persistence of URI definitions that has often
> been lamented by Larry Masinter.  In particular, since section 4 of the
> NI draft
> http://tools.ietf.org/html/draft-farrell-decade-ni-05#section-4
> specifies a mapping to http URIs, a URI such as
> http://example.com/.well-known/ni/sha-256/f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk 
> *permanently* identifies (within the limits of the hash algorithm) a
> particular chunk of information.  If that information were a URI
> definition, then

. . . that URI would be permanently associated with that particular URI
definition.  

[Sorry I forgot to finish that sentence!]

> 
> Note that this would bypass the dependence on the notion of a "URI
> owner" in authoritatively associating a URI with a particular URI
> definition, because it does not depend on the URI definition actually
> being served from that URI.  I.e., dereferencing the URI would not have
> to yield the URI definition (though it would certainly be helpful if it
> did).  Thus, anybody could have minted the URI -- not necessarily the
> owner of URI's domain.  
> 
> This may seem like it would be opening the gates to URI squatting
> http://lists.w3.org/Archives/Public/public-swbp-wg/2006Mar/0036.html
> but I do not think that is a technical problem in this case, because the
> whole purpose of .well-known is to enable a controlled form of URI
> squatting, and this is a good example.  
> 
> OTOH, if someone else against my wishes published URIs using
> http://dbooth.org/.well-known/ni/ as the prefix (i.e., under my domain),
> this could raise a security or legal concern, because it may mislead
> users of those URIs into thinking that I had sanctioned those URIs and
> therefore the content identified by those URIs.  Note also that this
> scenario would be significantly different from other cases in which a
> scammer squats on my URI space, because in the NI case the URI may
> function perfectly well *without* the need for any content to be served
> when the URI is dereferenced.  For example, the identified content might
> be obtained through a peer-to-peer protocol based solely on its identity
> (which is a big purpose of the NI RFC anyway).  Whereas normally, the
> scammer would need to be able to actually cause content to be served
> from that URI in order to be successful in the scam.  Since users often
> look at the domain name in a URI as a means of deciding whether content
> is trustworthy, I think this is a significant security issue that should
> be noted in NI RFC.  
> 
> For example, a scammer could mint an NI URI under my namespace and claim
> that it identifies a piece of software that I authored and released.  A
> user may see dbooth.org in the domain name of the URI, (wrongly) assume
> that the identified software was indeed from me, and allow that
> identified software to be downloaded via a peer-to-peer network and
> installed, thus compromising the user's system.
> 
> It seems to me that warning the user of this problem would not be
> sufficient, because most users are not likely to understand the issue in
> enough depth to realize that they really, really, REALLY should ignore
> the domain name in this particular case, in spite of the fact that in
> most other uses of URIs, the domain name is relevant to consider.  So
> perhaps one way to avoid this problem would be to avoid displaying the
> domain name to the user at all.   Or maybe someone else will have a
> better idea of how to mitigate this risk.
> 
> Aside from the above, which I will forward separately to the IETF list,
> I do not know of any particular input that the TAG should give to the
> authors of this proposed RFC.  It looks to me like a very nice piece of
> work.
> 
> David
> 
> On Tue, 2012-05-01 at 15:40 -0700, Larry Masinter wrote:
> > I think we talked about this under "naming things with hashes" (in
> > this case, not "#" hash-mark fragment identifier, but rather
> > hash-of-content).
> > 
> > http://tools.ietf.org/html/draft-farrell-decade-ni-05
> > 
> > I suggest looking at how this spec uses the word "resource". "
> > information-centric networking" might also be an interesting topic as
> > we talk about "local storage" also (see references).
> > 
> > Larry
> > 
> > 
> > -----Original Message-----
> > From: uri-review-bounces <at> ietf.org On Behalf Of Stephen Farrell
> > Sent: Monday, April 30, 2012 8:57 AM
> > To: uri-review <at> ietf.org
> > Cc: Barry Leiba; draft-farrell-decade-ni <at> tools.ietf.org
> > Subject: [Uri-review] Two new URI schemes for review
> > 
> > 
> > Hi,
> > 
> > We have a draft [1] that requests two new URI schemes.
> > 
> > The core WG are likely to want to use these we think
> > and possibly decade, but they're intended to be generally
> > useful as well.
> > 
> > Barry Leiba is planning to AD sponsor this and Alexey
> > Melnikov will be shepherding so if you can cc them ase
> > well as the authors on any questions or comments that'd
> > be good.
> > 
> > I hope the plan is to IETF LC this soon, once this
> > review and the .well-known registration review are
> > done.
> > 
> > Thanks,
> > Stephen.
> > 
> > [1] http://tools.ietf.org/html/draft-farrell-decade-ni-05
> > _______________________________________________
> > Uri-review mailing list
> > Uri-review <at> ietf.org
> > https://www.ietf.org/mailman/listinfo/uri-review
> > 
> > 
> > 
> 

--

-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Two new URI schemes for review

Hi,

We have a draft [1] that requests two new URI schemes.

The core WG are likely to want to use these we think
and possibly decade, but they're intended to be generally
useful as well.

Barry Leiba is planning to AD sponsor this and Alexey
Melnikov will be shepherding so if you can cc them ase
well as the authors on any questions or comments that'd
be good.

I hope the plan is to IETF LC this soon, once this
review and the .well-known registration review are
done.

Thanks,
Stephen.

[1] http://tools.ietf.org/html/draft-farrell-decade-ni-05