Ira McDonald | 19 Sep 18:45 2013

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


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:

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

- 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 - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
mailto:blueroofmusic <at>
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>
Jan Pechanec | 14 Aug 02:50 2013

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:


	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 

	(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

	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>>
Mirko Nosenzo | 13 Aug 14:20 2013

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.


/*  Mirko Nosenzo   /   Software Architect   /   Incomedia   */
/*  mirko.n <at>   /            */

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


The core of the registration seems to be this

Scheme syntax:
   feedready:<absolute_uri> or feedready://<hierarchical part>
   examples: feedready:// and feedready:

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?



Uri-review mailing list
Uri-review <at>
Mirko Nosenzo | 9 Aug 12:25 2013

Review Request of new URI Scheme

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:// and feedready:

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.

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

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


/*  Mirko Nosenzo   /   Software Architect   /   Incomedia             */
/*  mirko.n <at>   /                       */
DataPacRat | 13 Jun 20:42 2013

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 and ; the
contents of which I'll paste below for ease of future reference.

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:’ ( , ), 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

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:


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, “”)
* 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,
* 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
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: <at>,2013-06-05;(,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.;(KEY;PGP: asserts that its public key can be found at a particular URL.,2000;(ID1),2001 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.,2000-12-31;(ID1),2001-01-01?-100 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 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.)
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.


Thank you for your time,
"Then again, I could be wrong."
Uri-review mailing list
Uri-review <at>
Kang Su Gatlin | 6 Jun 01:10 2013

Review Request of new URI Scheme

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



   Resource Identifier (RI) Scheme name:
   Scheme syntax:

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

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

   Interoperability considerations:
   Security considerations:
     urischemeowners <at>
   Author/Change controller:
      urischemeowners <at>



Uri-review mailing list
Uri-review <at>
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 
( ) 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 for of one of the 
conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of for comments from well-known researchers 

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 

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   Search Google using the 
keyword worldcomp fake for additional links.

Uri-review mailing list
Uri-review <at>
Fredrik Ullner | 20 Feb 21:26 2013

URI scheme registration request - dchub


This is a request for registration of an URI scheme, dchub. The scheme can be viewed at <>.

The URI scheme should meet the necessary requirements for a Permanent URI scheme, as indicating in RFC 4395. The scheme specifies encoding, interoperability and security aspects (and more). If the scheme should not provide enough information for a Permanent scheme, please specify what is lacking or at least consider a Provisional request instead.

Fredrik Ullner
Uri-review mailing list
Uri-review <at>
Jan Pechanec | 26 Jan 23:38 2013

PKCS#11 URI registration request review


	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:

	the registration template is attached.

	best regards, Jan Pechanec

Jan Pechanec
# 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>>

The template references sections in the following I-D:

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


	- in gnutls_pkcs11_obj_info_t structure
	- parser is in pkcs11_get_info())
	- in libgck library used by gnome-keyring since version 3.3.5


	- parsing function is p11_kit_uri_parse()

	- 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

References: Section "7.  References"
Uri-review mailing list
Uri-review <at>
Peter Saint-Andre | 10 Jan 04:32 2013

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



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


4.2. Status


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

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>

4.10. Author/Change Controller

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

4.11. References


Gonzalo Salgueiro | 9 Jan 19:51 2013


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 ( and 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:



The TURN URI scheme was first proposed several years ago and has already been through uri-review back in
late 2009 ( 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.



Begin forwarded message:

> From: Pete Resnick <presnick <at>>
> Subject: Re: TURN/STUN URI Drafts
> Date: January 3, 2013 11:23:28 AM EST
> To: Marc Petit-Huguenin <petithug <at>>
> Cc: Gonzalo Camarillo <Gonzalo.Camarillo <at>>, Gonzalo Salgueiro <gsalguei <at>>,
"Suhas Nandakumar (snandaku)" <snandaku <at>>, Paul Jones <paulej <at>>, Cullen
Jennings <fluffy <at>>, Barry Leiba <barryleiba <at>>
> Happy New Year to you as well.
> You should probably first send these drafts to uri-review <at> 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:
>> 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:
>>>> 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 ( and
>>>> 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>
>> Blog:
>> Profile:
>> Version: GnuPG v1.4.12 (GNU/Linux)
>> 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<>
> Qualcomm Technologies, Inc. - +1 (858)651-4478