Ben Beltran | 7 Jul 18:18 2014
Picon

Request for Provisional URI Scheme recordit

Hello,

I would like to submit a request for a provisional URI scheme. The request is located here: https://gist.githubusercontent.com/benbeltran/5fb9f0396037d7f7fc50/raw/68cc526d5eff9d4fd0208493fa90b57db42fb8a8/gistfile1.txt

Thank you

-- 
Ben Beltran

_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review
Ben Beltran | 27 Jun 18:10 2014
Picon

Re: Confirm: uri-review <at> ietfa.amsl.com:U6l4YA7NdPYR:9uRl5qsERCviWf4FW_C74crqeALLhNMC31at5A

another, huh...

-- 
Ben Beltran

On Tuesday, June 24, 2014 at 8:08 AM, uri-review <at> ietfa.amsl.com wrote:


Confirmation of list posting -- confirmation ID: U6l4YA7NdPYR

The ietf.org mailing-list server has received a list posting from
'Re: Confirm:
=?utf-8?Q?uri-review=40ietfa.amsl.com=3AU6l3-wxxJogz=3ART5V4YFlvlG7H0c8NZpSkclbsMRvQfOOKtIEKg?='

As the sender address isn't subscribed to the list, and has not been
confirmed earlier, we have to request a confirmation of the address.
To confirm the address, send a message to uri-review <at> ietfa.amsl.com,
with the same subject line as this message.

(Simply sending a 'reply' to this message should work from most email
interfaces, since that usually leaves the subject line in the right
form. The reply's additional "Re:" is ok.)

If you do not wish your posting to the list to go through, simply
disregard this message. Questions to postmaster <at> ietf.org.

_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review
Daniel Pocock | 7 May 09:10 2014

registration request for "call:" URI prefix



URI scheme name call - The call: URI scheme can be used to refer to radio callsigns. "call:" does not imply an action, it is used as a noun in this context. Status Provisional URI scheme syntax The parameter is a callsign, e.g. for amateur radio call signs: call:vk3tqr call:M0GLR URI scheme semantics As per the ITU recommendations[1] Encoding considerations Only ASCII alphanumeric symbols are permitted. Case insensitive. Applications/protocols that use this URI scheme name Morse code Interoperability considerations TBD Security considerations None. Contact Daniel Pocock, daniel <at> pocock.pro Author/Change controller Daniel Pocock, daniel <at> pocock.pro References 1. http://life.itu.int/radioclub/rr/res-13.pdf
_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review
Gerardo Capiel | 27 Apr 08:35 2014

Registration request for math: URI scheme

Hi, I'm requesting a provisional 'math' URI scheme name. The 'math' URI scheme and protocol handler can be used by Web browsers and other applications to transport mathematical expressions to other applications, such as Assistive Technologies or graphing calculators. Below is the provisional URI Scheme Registration Template: URI scheme name math - The math: URI scheme can be used by Web browsers and other applications to transport mathematical expressions to other applications, such as Assistive Technologies or graphing calculators. Status Provisional x URI scheme syntax Applications launched via the math protocol take as a parameter either a URL to a resource containing a mathematical expression in MathML or other formats or the actual math expression in uncompressed or compressed form. For example: math://mathmlcloud.org/m/uniqueexpressionid math:<math><mi>x</mi><mo>+</mo><mn>2</mn></math> math:<math-compressed>someexpressionincompressedformat</math-compressed> URI scheme semantics TBD Encoding considerations TBD Applications/protocols that use this URI scheme name Applications should register the math: protocol handler with this scheme. Interoperability considerations TBD Security considerations None known. Contact Gerardo Capiel, gcapiel <at> alum.mit.edu Author/Change controller Gerardo Capiel, gcapiel <at> alum.mit.edu References [1] http://www.w3.org/community/groups/proposed/#mathprotocol [2] https://wiki.benetech.org/display/MATH/Protocol+Handlers+for+External+Applications+to+Process+MathML Gerardo Capiel VP of Engineering benetech

_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review
Ira McDonald | 19 Sep 18:45 2013
Picon

Request for Apps Area review of IPP over HTTPs and 'ipps' URI Scheme (19 September 2013)

Hello,

The IEEE-ISTO PWG Internet Printing Protocol WG would like to request
IETF Apps Area review of our IPP over HTTPS Transport Binding and
'ipps' URI Scheme:

http://www.ietf.org/internet-drafts/draft-mcdonald-ipps-uri-scheme-08.txt

Please note that this document has been already been reviewed on the
IETF URI Review mailing list (and revised accordingly).

This document does NOT specify a new protocol, but merely a transport
binding for IETF IPP/1.1 (RFC 2910/1911) that requires that TLS always
be started *before* sending any HTTP application layer requests - as
opposed to using the rarely implemented HTTP Upgrade (RFC 2817),
a source of security problems in shipping IPP printers (essentially all
network printers for the last decade).

Cheers,
- Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document)


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic <at> gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

_______________________________________________
apps-discuss mailing list
apps-discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
Jan Pechanec | 14 Aug 02:50 2013
Picon

percent encoding of '/' in one-segment non-hierarchical path component


	hi experts,

	I've recently asked here for your opinion on the PKCS#11 URI 
draft.  With your review help which I very much appreciated, the scheme 
was recently approved as a provisional scheme and I'm getting ready to 
put it on RFC tracker.

	however, there is one thing I'm not sure about and I'd like to 
ask for your opinion.  The following is an example of a pkcs11 URI:

	pkcs11:object=my-key;object-type=private;pin-source=%2Fetc%2Fpin

	now, I have the following paragraph in my draft:

   ...
   More specifically, '/' delimiter of generic URI components was
   removed from available characters that do not have to be percent-
   encoded so that the initial part of a PKCS#11 URI is never confused
   with "path-rootless" part of the "hier-part" generic URI component as
   defined in Section 3 of [RFC3986].
   ...

	which is not entirely precise (I should also include 
"path-noscheme", too) and should be rephrased.  Basically what I want to 
say is that the scheme requires encoding of '/' so that generic URI 
parsers do not split the path into segments and parse the URI above as:

	scheme name:	pkcs11
	path-segment-1:	object=my-key;object-type=private;pin-source=
	path-segment-2:	etc
	path-segment-3:	pin

	I could easily fix the draft but I'm still wondering whether:

	(1) '/' is really needed to be removed from a charset that does 
NOT have to be percent-encoded

	(2) to allow non-encoded '/' and mention that if '/' are not 
percent encoded the generic URI parser may split the intended 
non-hierarchical one-segment path (ie. set of attributes) into multiple 
segments

	(3) to allow non-encoded '/' and does not discuss the generic 
parser issues

	it's easy to guess that people will use unencoded slashes in the 
pin-source attribute no matter what I do and that PKCS#11 URI parsers 
will have to accept it.  Choosing (1) then seems a bit useless to me.  
I'm leaning to (2) but I'm not sure it's permissible to do that.

	I'm reading rfc3986 again.  "2.2. Reserved Characters" suggests 
that since '/' is not a delimiter in the PKCS#11 URI, it does not have 
to be percent encoded.  Also, the next paragraph also under 2.2 makes me 
think that (2) might be really a good solution since '/' can be part of 
the pin-source attribute data:

   ...
   URI producing applications should percent-encode data octets that
   correspond to characters in the reserved set unless these characters
   are specifically allowed by the URI scheme to represent data in that
   component. 
   ...

	however, I'm really not sure and still thinking about generic 
parsers splitting the path into multiple segments.  I'm hoping you could 
help me with some insight.

	best regards, Jan.

--

-- 
Jan Pechanec <jan.pechanec <at> oracle.com>
Mirko Nosenzo | 13 Aug 14:20 2013
Picon

Re: Review Request of new URI Scheme

Hi Ted,
feedready:// uses http but by using feedready:<absolute_uri> the user can specify a different protocol.
Actually the app supports http and https only.

Since the resource is simply downloaded, the fragment is ignored.

Thanks,
Mirko

/*******************************************************************/
/*  Mirko Nosenzo   /   Software Architect   /   Incomedia   */
/*  mirko.n <at> incomedia.eu   /   http://incomedia.eu            */
/*******************************************************************/

Il giorno 12/ago/2013, alle ore 19:31, Ted Hardie <ted.ietf <at> gmail.com> ha scritto:

Howdy,

The core of the registration seems to be this

Scheme syntax:
   feedready:<absolute_uri> or feedready://<hierarchical part>
   examples: feedready://example.com/rss.xml and feedready:https://example.com/rss.xml

feedready as a scheme with a 3986 hierarchical part seems to be pretty easy to parse. I'm a little concerned, though, about the other form, which apparently takes an unescaped URI as an argument but is presented as if it were a hier-part.  Does this get used with anything other than http and https?  You're also sure that this can never be used with a fragment?

regards,

Ted

_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review
Mirko Nosenzo | 9 Aug 12:25 2013
Picon

Review Request of new URI Scheme

Hello,
please review the following URI scheme:

-------------------------------------------------------------------
Resource Identifier (RI) Scheme name: feedready 

Status: provisional

Scheme syntax:
   feedready:<absolute_uri> or feedready://<hierarchical part>
   examples: feedready://example.com/rss.xml and feedready:https://example.com/rss.xml

Scheme semantics:
   FeedReady is a feed reader application developed by Incomedia.

Encoding considerations:
   Unknown, use with care.

Applications/protocols that use this scheme name:
   FeedReady application

Interoperability considerations:
   Unknown, use with care.
   May be unsuitable for open use on the public internet.

Security considerations:
   Unknown, use with care.

Contact:
   Registering party: Mirko Nosenzo <mirko.n <at> incomedia.eu>
   Scheme creator: Incomedia

Author/Change controller:
   Either the registering party or someone who is verified to represent
   the scheme creator.  See previous answer.

References:
   http://feedready.com
-------------------------------------------------------------------

Thanks,
/*******************************************************************/
/*  Mirko Nosenzo   /   Software Architect   /   Incomedia             */
/*  mirko.n <at> incomedia.eu   /   http://incomedia.eu                       */
/*******************************************************************/
DataPacRat | 13 Jun 20:42 2013
Picon

Initial inquiry into URI proposal (nym)

For my own purposes, I’ve started roughly defining a pseudo-URI,
loosely based on ‘tag:’. I initially put it together to use as a
framework for authenticating a peer-to-peer reputation system, but it
seems as if it could be general enough for many other uses, as well.

Going through the process of writing up a full Internet Draft proposal
is a bit of an effort for a personal toy URI, but I don't mind doing
so - if it actually is something worth doing. As far as I can tell,
this mailing list seems to be the most appropriate place to ask the
question: Does nym: meet the very basic requirement for a URI, of
providing "clear utility to the broad Internet community, beyond that
available with already registered URI schemes"? If there's a consensus
here that it does, then I'll try to fill out a scheme registration
template, and proceed as RFC 4395 suggests from there. If not, then I
apologize for taking up your time.

I've posted some of my initial notes at
http://blog.datapacrat.com/2013/06/08/early-draft-for-nym-uri/ and
http://blog.datapacrat.com/2013/06/10/nym-first-improvements/ ; the
contents of which I'll paste below for ease of future reference.

-----8<-----

http://blog.datapacrat.com/2013/06/08/early-draft-for-nym-uri/
Early draft for ‘nym’ URI
June 8th, 2013 by DataPacRat

For my own purposes, I’m putting together a new pseudo-URI, loosely
based on ‘tag:’ ( http://www.taguri.org/ ,
https://tools.ietf.org/html/rfc4151 ), to use for peer-to-peer
distributed reputation systems. What I am aiming for is a common
protocol that can easily express this idea: “Authority A asserts that
X and Y refer to the same entity” (with a certain amount of certainty)
(with an optional comment field) (with an optional authentication
hash). Depending on how well it works, I may even look into the
Internet Draft submission process to put it on the track to become
official.

Early draft for ‘nym’ URI

In math, ’0.999…’ and ’1′ are different representations of the same
underlying concept. Multiple social media profiles and contact methods
can represent the same underlying person. Books can be referred to by
their author and title, or their ISBN. The ‘nym’ URI announces that a
given authority asserts that two or more representations both refer,
at least in a general sense, to the same thing; that is, they describe
the same entity in different formats.

Preliminary formatting structure idea:

nym:Authority[,date]:(Identity1)[,date];(Identity2)[,date][;(Identity3)[,date]][?comment1[&comment2][#authenticationHash]

The ‘date’ fields can be any valid ISO 8601 date or time-and-date. If
present, they should contain at least a four-digit year. The date for
the authority field may indicate any time when the authority field
referred to the authority making the assertion, in the same fashion as
the “tag:” URI. The date for the authority field should refer to a
date reasonably closely correlated with when the authority is making
the assertion. The dates for the identity fields, if present, should
refer to a point in time when that identity is connected to the
underlying entity.

The Authority and Identity fields can be any relevant string. In
descending order of preference, these should be:
* Well-formed URIs (eg, “http://www.example.com/SocialMediaProfile”)
* Email addresses lacking the “mailto:” header (which should be
assumed to be identical to a field containing that header)
* Domain names
* Valid vCard property types (such as “key:” to indicate a public
encryption key)
* Valid FOAF property labels (such as “openid:”)
* Some other field of the form “generalLabel:particularEntity” (eg,
“LibraryCard:23043001054082″)
* Any other string

The Authority and Identity fields may have characters escaped. If they
contain characters which would allow for misinterpretation of the
overall nym statement, they must be escaped. The fields may be
enclosed in quotation marks.

The comment fields may contain additional information, which is
peripheral to the relationship being asserted between the Identities.
Possible uses may include trustcloud whuffie scores, or how the
authority knows the individual being identified.

If a comment field is a number, that number is assumed to be how
confident the authority is that all the listed identifiers all refer
to the same entity, measured in decibans. (Decibans are logarithmic,
with 0 decibans being equivalent to 1:1 odds, or being 50% confident;
10 decibans to 10:1 odds, or ~90% confident; 20 decibans to 100:1
odds, or ~99% confident; and so on.) It is recommended that these
numbers be integers, unless there is a specific reason to be able to
specify confidence to greater accuracy; and with a magnitude under
128, as it requires extraordinary effort to have 100 decibans of
confidence for even the most fundamental facts. If no specific
confidence field is entered, the confidence value of the overall nym
statement should only be assumed to be ‘greater than zero’.

While people tend to be very bad at assigning accurate confidence
levels (eg, when people claim to be 90% sure of something, they’re
often wrong 50% of the time), their initial estimates of their
confidence levels can be used as the inputs for more sophisticated
Bayesian algorithms. Until such time as more accurate estimates are
available, here are some possible sample confidence levels:
0 decibans: 50%: You’re not sure whether the last digit of the phone
number is a 3 or a 5.
1 decibans: 55% Just slightly more likely than not; a business card
handed to you by a stranger.
Up to 10 decibans: to 90%: Someone you’ve chatted to for an evening.
Up to 20 decibans: to 99%: A distant acquaintance, who you talk to once a year.
Up to 30 decibans: to 99.9%: A co-worker who might have been
re-organized into a new email since you last heard from them.
Up to 40 decibans: to 99.99%: A family member, who you might
accidentally have mis-spelled the email address of.
Around 100 decibans: Your own personal information, closely checked.
(There’s still a theoretical chance that you’re wrong, just as there’s
a theoretical chance that you’re the star of something like the Truman
Show.)
127 decibans: Data which relies on yourself alone, thoroughly
re-checked and confirmed by others.

The authentication hash is to provide strong evidence that the listed
authority is actually the one making the assertion. By default, it is
assumed to be based on whatever public cryptographic key (eg,
PGP/GnuPG or X.509) is linked to the listed authority ID; and that
what is being signed is the string of text before the hashmark.

Some examples:

nym:datapacrat.com:(datapacrat <at> datapacrat.com),2013-06-05;(http://twitter.com/DataPacRat),2013-06-05;(Daniel
Eliot Boese)?100&TrustCloud,774&Klout,29#randomhashofletters

… to indicate that as of that particular date, I indicate with
extremely high confidence that my name, email address, and Twitter
account all point to me, and that I have two social media scores.

nym:example.com:(example.com);(KEY;PGP:http://example.com/key.pgp)

Example.com asserts that its public key can be found at a particular URL.

nym:example.com:(ID1),2000;(ID1),2001

Example.com asserts that that the same identity referred to the same
individual on two different dates. Unless some other nym statement is
made, it may be assumed that what is being asserted is that the
identity referred to the same individual during the entire period
between those dates.

nym:example.com:(ID1),2000-12-31;(ID1),2001-01-01?-100

Example.com asserts with strong confidence that ID1 referred to an
entity on one day, but did not refer to it on another day. This can be
used to revoke an identity, such as if example.com shut down a social
media account. (Note that a nym statement with a positive confidence
level asserts that /all/ the identities refer to the same entity;
while a nym statement with a negative confidence level assrts that /at
least one/ of the identities does not refer to the same entity as the
others. Thus, in order to make what identity is being revoked clear,
the revocation statement should only contain two identity fields.)

http://blog.datapacrat.com/2013/06/10/nym-first-improvements/
Nym: First improvements
June 10th, 2013 by DataPacRat

Recursion and reflexivity: If nym ever does become a formal IETF spec,
then it would be a full-fledged URI; which would mean that the
Identity fields in a nym could themselves be nyms. I don’t see any
reason to rule this out, as long as it’s made clear that if a nym is
used as an identifier, the identifier is referring to the act of
assertion made by the nym rather than whatever that nym is itself
referring to.

Time periods: ISO 8601 and RFC 3339 allow for time-strings that don’t
just refer to a moment, but to an extended period of time. This seems
to be quite useful, such as using the string “2000/P1Y” to refer to
the whole of that year. And since the current draft for nym’s format
doesn’t use the “/” character, no extra ambiguities seem to be
introduced by allowing such date-fields.

Next up: Looking up whether there are any ISO or RFC standards on
numbers and mathematical notation; and checking on whether it’s
meaningful to measure decibans with complex numbers, or if nym should
limit the confidence field to real numbers.

----->8-----

Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."
_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review
Kang Su Gatlin | 6 Jun 01:10 2013
Picon

Review Request of new URI Scheme

Hello, I am requesting review for the following URI scheme:

 

 

   Resource Identifier (RI) Scheme name:
      ms-settings-power
   Status:
      provisional
   Scheme syntax:
      ms-settings-power

   Scheme semantics:
      Launches the battery saver settings application.
   Encoding considerations:
      None

   Applications/protocols that use this scheme name:
      Battery Saver settings application in Windows Phone.

   Interoperability considerations:
      None
   Security considerations:
      None
   Contact:
     urischemeowners <at> microsoft.com
   Author/Change controller:
      urischemeowners <at> microsoft.com

   References:
      http://www.windowsphone.com/en-us/how-to/wp8/basics/battery-making-it-last

 

_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review
hammondjohnson | 27 Apr 19:53 2013

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

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

Gmane