Review of proposed URI schemes

headers Larry Masinter | 21 Jan 22:04

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

Hi,

  I was wondering if the 'jar' scheme could be defined in an hour or so,
and so I experimented a bit, comparing the implementation in Firefox and
the Sun Java implementation I had laying around, and they are nothing a-
like when it comes to parsing; simple example `jar:...!/...?example`; in
this case, Firefox ignores the "?example" string while Java treats it as
part of the file name. At best one could define a tiny profile that does
not allow any "special" cases like that without creating some ficition,
or for that matter simply refer to the Java documentation which does not
address these things and leave it at that.

regards,
--

-- 
Björn Höhrmann · mailto:bjoern <at> hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
_______________________________________________
Uri-review mailing list
Uri-review <at> ietf.org
https://www.ietf.org/mailman/listinfo/uri-review

It looks like most URI schemes like this one are never registered with
IANA. It seems like The Right Thing to do and so I present to the list
the URI scheme com-eventbrite-attendee.

URI scheme name.
    com-eventbrite-attendee

Status.
    provisional

URI scheme syntax.
    uri = "com-eventbrite-attendee:" method [ "?" query ]
    method = "resetpassword" / "tickets"

    Example:

        com-eventbrite-attendee:resetpassword?email=user%40domain.com&token=DEADBEEF

URI scheme semantics.
    This scheme is intended to be used by operating systems that have the
    Eventbrite Attendee application installed. When a URI with
    this scheme is encountered it is expected that the operating system
    launches the Eventbrite Attendee application with the method and
    query parameters specified in the URI.

    The exact semantics for how URL information is communicated to the
    Eventbrite Attendee app may vary on an operating system basis. The
    expectation is simply that the operating system follows its own
    conventions for passing the method and query parameters into the
    application.

Encoding considerations.
    The scheme and method portions of this proposed URI avoid encoding
    issues by limiting itself to a subset of ASCII.

    The query portion of a com-eventbrite-attendee URI shall be encoded
    according to the rules in RFC 3986.

Applications/protocols that use this URI scheme name.

    - Eventbrite Attendee for iOS
    - Eventbrite Attendee for Android

Interoperability considerations.
    none.

Security considerations.
    Against recommendations in RFC 3986 section 7.5 a
    com-eventbrite-attendee: URI may be used to transmit sensitive
    information. For example, it may be used to communicate a password
    reset token in email for a user following a "Forgot your password"
    flow. Though this token may have transmitted over insecure channels
    on its way to the application care must still be taken by
    application developers to not divulge this secret.

    RFC 3986 sections 7.2 and 7.5 apply

Contact.
    Bob Van Zant
    Eventbrite
    651 Brannan St
    San Francisco, CA 94103
    USA

    EMail: bob <at> eventbrite.com

Author/Change controller.
    Bob Van Zant

References.

    Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
    Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
    January 2005.

Hi,

I've seen 'udp' URIs before for a number of times and can see it in 
front of my eyes right now, in uTorrent, listed along with 'http' URIs 
in the trackers list.  I have the URI like 
<udp://tracker.somehost.com:80/announce>, and such URI makes me think 
that it's in some way related to HTTP, as port 80 is used.  OTOH, one 
may also think it's related to UDP, which seems to be obvious from the 
scheme name.

Official IANA registry says nothing about it; neither does Wikipedia 
(http://en.wikipedia.org/wiki/URI_scheme).  I've found the 1999 draft, 
though, proposing two schemes for HTTP-over-UDP: 
http://tools.ietf.org/html/draft-goland-http-udp-01.  So does anybody 
know how is it related to 'udp' scheme and what the latter stands for at 
all?

Mykyta Yevstifeyev

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

URI scheme name:
   pack
Status:
   historical
URI scheme syntax:
   There was no pack: syntax compatible with STD 66, cf.
   <http://www.ietf.org/mail-archive/web/uri-review/current/msg00678.html>,
   <http://www.ietf.org/mail-archive/web/uri-review/current/msg00548.html>.
URI scheme semantics:
   n/a due to a lack of STD 66 syntax.
Encoding considerations:
   The pack: encoding assumed US-ASCII after un-escaping percent-encoded
   characters in an encapsulated <authority> (4.c in the expired drafts)
   and case-insensitive US-ASCII in the <path> (5.c in the expired drafts).
Applications/protocols that use this URI scheme name:
   The pack: scheme could not be used as an URI scheme in applications
   or protocols.  Other uses of pack: are noted in the expired drafts.
Interoperability considerations:
   All URI schemes have to follow the generic STD 66 syntax, as that was
   not the case for pack: any "interoperability" would be by the chance
   of similarly broken implementations.
Security considerations:
   The generic and overall URI syntax is specified in STD 66, anything
   else (not limited to pack:) is no URI and could cause havoc, compare
   <http://www.kb.cert.org/vuls/id/358017>.
Contact:
   <uri-review <at> ietf.org> and <uri <at> w3.org> mailing lists.
Author/Change controller:
   IESG (the transition from a "provisional" to "historical" status is
   not covered by BCP 35 section 5.3; maybe the pack: scheme could be
   simply identified as "non-URI" and removed from the scheme registry).
References:
   STD 66 (RFC 3986), I-D.shur-pack-uri-scheme-05 (same as -03 and -04).

Hello,

draft-mcdonald-ipps-uri-scheme will expire on 28 August, and could you 
please notify whether you're planning to continue work on it, and, 
explicitly, incorporate my comments from [1] and [2]?  The last activity 
with respect to this draft, I recall, was in the beginning of 2011, and 
no new versions of the draft appeared.

Mykyta

[1]http://www.ietf.org/mail-archive/web/uri-review/current/msg01368.html
[2]http://www.ietf.org/mail-archive/web/uri-review/current/msg01370.html

Hello all,

I uploaded new version of draft-yevstifeyev-ftp-uri-scheme several days ago:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : The&#39;ftp&#39; URI Scheme
> 	Author(s)       : Mykyta Yevstifeyev
> 	Filename        : draft-yevstifeyev-ftp-uri-scheme-06.txt
> 	Pages           : 29
> 	Date            : 2011-08-11
>
>     This document specifies the&#39;ftp&#39; Uniform Resource Identifier (URI)
>     scheme, which is used to refer to resources accessible via File
>     Transfer Protocol (FTP).  It updates RFC 959 and RFC 1738.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-yevstifeyev-ftp-uri-scheme-06.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-yevstifeyev-ftp-uri-scheme-06.txt

Also see 
http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-06.  Please 
let me know if you have any further comments.

Thanks,
Mykyta Yevstifeyev

Hello,

Skype(tm) is known to use 'skype' and 'callto' URI schemes.  There is no 
any clear specification of the schemes on the Skype site, nor can I find 
it on the Net.  However, the syntax is known; it is said to be 
(transforming into ABNF):

> skype-uri      = "skype:" name [params]
> name           = telephone-subscriber / skype-username
> telephone-subscriber = <as defined in RFC 3966>
> skype-username = ALPHA 5( ALPHA / DIGIT ) *26( ALPHA/DIGIT)
> params         = "?" param
> param          = "add" / "call" / "chat" / "sendfile"
>                / "userinfo" / ext-param
> ext-param      = 1*ALPHA
>
> callto-uri     = "callto:" name

The operations of 'callto' URIs are to open a Skype call to <name>; 
'skype' URI provide richer semantics, per <params>.  Documentation for 
Skype operations is available from 
share.skype.com/media/1.2_api_doc_en.pdf (this document says it is 
confidential .

The 'skype' URIs are known to be widely used; 'callto' are also used, 
but not as often as 'skype'.  Currently, the schemes are not officially 
registered with IANA; so my questions is: Can (should?) an effort to 
specify these two schemes be undertaken?  Any thoughts are welcome.

Mykyta Yevstifeyev

Hello Bjoern, all,

I'm copying this to uri-review list.  These are comments on 
draft-hoehrmann-javascript-scheme 
(http://tools.ietf.org/html/draft-hoehrmann-javascript-scheme-03), 
currently expired (these comments are in no particular order).

Some substantial comments:

As I identified before, the document is missing the syntax description.  
URIs have a limited number of allowed characters; some disallowed ones 
might be legal in Javascript code.  Therefore, if you define the URI 
scheme, those characters which do not suit to <unreserved> production of 
RFC 3986 should be percent-encoded within such URI, and this should be 
mentioned in the specification.  If you define IRI scheme, <reserved> in 
RFC 3987 are the same as in RFC 3986, which should be considered.  
Anyway, it's better to have formal definition of syntax using ABNF, even 
though it is going to be smth. like:

>      javascript-uri = "javascript:" code
>      code           = segment
>
>    where <segment> rule is defined in RFC 3986 [RFC3986].
If you add this ABNF, the following should be changed in Section 3:

>        1.  Represent the scheme-specific part as sequence of octets in
>            the UTF-8 character encoding.
s/the scheme-specific part/the <code> part.

Other comments to Section 3.
>        2.  Replace any percent-encoded octet by its corresponding octet.
s/corresponding octet/corresponding ASCII character (or UCS character, 
if you decide to define IRIs).

>        3.  If the sequence starts with the sequence 0xEF 0xBB 0xBF, the
>            UTF-8 signature, then discard this signature.
Probably editorial.  This is a tautology; I propose

>        3.  If the obtined chain of octets starts with 0xEF 0xBB 0xBF,
>            which is the UTF-8 signtaure, ignore these 3 octets.
Next,

>        4.  Decode the octet sequence using the UTF-8 character encoding
>            and transform the result into source text.
Probably it would be better to mention "Decode the octet sequence using 
the algorithm defined in Section 3 of RFC 3629; obtained ASCII text 
should be considered to be Javascript source code."

Section 3.2 (and global): I don't see why you chose the name "In-context 
evaluation".  Shouldn't "In-context execution" be better?

Section 7 is missing registration template required by RFC 4395 
(http://tools.ietf.org/html/rfc4395#section-5.4).

29.06.2011 19:36, Bjoern Hoehrmann wrote:
> * Mykyta Yevstifeyev wrote:
>> Actually, I have identified a number of other issues, the main of which
>> is absence of section dedicated to syntax of the javascript URI.  There
>> are a number of editorial flaws, too.  So please, when you decide to
>> proceed, reconsider my offer.
> The Conformance section is dedicated to syntax. There is nothing more to
> it as it's just "javascript:" followed by the scheme specific part which
> is restricted in prose as that is not feasible in ABNF beyond "anything
> goes" if you have a proper IRI to begin with. Editorial problems, please
> do report, either to me directly or uri-review or wheverever.
Among other minor/editorial issues:

Global: s/resource identifier/URI (should be explained in Abstract when 
first mentioned as Uniform Resource Identifier) or IRI, dependent on 
what you define.  I suppose URI is a better term for 'javascript' RI.

Abstract:

>     Using
>     this scheme, executable script code can be specified in contexts that
>     support resource identifiers.

I propose:

>     Using 'javascript' URIs, Javascript (also known as ECMAScript)
>     executable code may be specified in such URI and executed by
>     the application resolving it.

Section 2:

>    Resource identifiers, including percent-encoding and requirements for
>    IRIs, are defined in STD 66, [RFC3986], and [RFC3987].  Source text
>    and the media type application/javascript are defined in [RFC4329],
>    the 'data' scheme in [RFC2397], and UTF-8, including the term byte
>    order mark, in STD 63, [RFC3629].

I think mentioning specification for these terms in the text of the 
document itself rather than combining them in one section seems to be a 
better option.  This will add clarity to the document.

Section 1:

>     The first operation, source text retrieval, defines which script code
>     a given 'javascript' resource identifier represents.
Maybe here s/defines which script code/defined how to determine the 
script code.

Ibid:

> <a href='javascript:doSomething()'>...</a>
For the purpose of an example, it would be better to mention something like

> <a href='javascript:doSomething()'>Run doSomething</a>
Ibid:

>     script, style sheet, HTML document, resource identifier, or other
>     type of resource, as appropriate for the context.
Considered you provide this list as an illustration of the previous 
phrase "like an Internet media type, how to process it" I should note 
URIs aren't classified as some media type so it's better to remove URIs 
from this list.  Moreover, probably you meant "MIME media type", not 
"Internet media type".  Also, informative reference to RFC 2046 is 
probably missing.

I hope my remarks were useful.

Thanks,
Mykyta Yevstifeyev

3	January 2012
4	November 2011
17	October 2011
1	September 2011
21	August 2011
19	July 2011
27	June 2011
33	May 2011
41	April 2011
11	March 2011
27	February 2011
22	January 2011
2	December 2010
32	November 2010
12	October 2010
26	September 2010
5	July 2010
5	June 2010
45	May 2010
17	April 2010
4	March 2010
25	February 2010
4	January 2010
1	December 2009
14	November 2009
58	October 2009
60	September 2009
73	August 2009
10	July 2009
1	June 2009
9	May 2009
4	April 2009
1	February 2009
2	January 2009
7	December 2008
5	November 2008
3	October 2008
1	July 2008
1	May 2008
8	April 2008
1	March 2008
7	February 2008
2	January 2008
5	November 2007
6	October 2007
8	September 2007
7	June 2007
10	May 2007
7	March 2007
6	February 2007
14	January 2007
7	December 2006
33	November 2006
1	October 2006
22	July 2006
5	June 2006
14	May 2006
9	March 2006
1	February 2006
3	July 2005
10	March 2005
1	February 2005
2	January 2005

'duri' and 'tdb' => Experimental (= Provisional registration)

The 'jar' scheme

Request for review of draft-mcdonald-ipps-uri-scheme

New URI scheme for review

'udp' URIs?

Request for review of draft-mcdonald-ipps-uri-scheme

Request for review

draft-mcdonald-ipps-uri-scheme

Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-06.txt

'skype' and 'callto' schemes

Comments on draft-hoehrmann-javascript-scheme (was: Proposal regarding draft-hoehrmann-javascript-scheme)

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29