gmane.ietf.uri-review

Re: Request to review sieve URI scheme

Alexey Melnikov — 2008-12-01T11:02:45

Hi Bjoern, Bjoern Hoehrmann wrote: Thanks for spotting that. Fixed. Yes. I had a note at the top of the ABNF, but I guess it wasn't clear. I've deleted uchar, as it wasn't used. I've added a note on that. Sure. Added. Yes, I will fix that. Thank you for your review, Alexey

Re: Request to review sieve URI scheme

Martin Duerst — 2008-12-01T10:24:23

Hi Alex, At 19:17 08/12/01, Alexey Melnikov wrote: In that case, I guess it would be better to say so in a note. The principle in URI escaping is that escaping isn't necessary in those parts where the character doesn't take a special meaning, so people familiar with that principle could think that it's not really necessary to escape these. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst< at >it.aoyama.ac.jp

Re: Request to review sieve URI scheme

Alexey Melnikov — 2008-12-01T10:17:24

Hi Martin, Martin Duerst wrote: Good point. I've reordered them. Yes. I don't have any extensions in mind yet, but I thought it would be better to allow for them. Thank you, Alexey

Re: Request to review sieve URI scheme

Martin Duerst — 2008-12-01T02:46:27

I had a look at parts of it. One thing I looked through is whether it's clear where (percent-encoded) UTF-8 can be used; that seems to be fine. It might help the reader if the grammar rules were reordered to read top-down. Currently it's top-down first, but then bottom-up. Another thing I noticed is that characters such as "&" and "=" are listed as needing percent-encoding. I don't see them being used in the syntax, so it wouldn't be necessary to percent-encode them. Or are they reserved for future extensions? Regards, Martin. At 02:56 08/12/01, Alexey Melnikov wrote: #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst< at >it.aoyama.ac.jp

Re: Request to review sieve URI scheme

John Larmouth — 2008-11-30T20:07:23

Bjoern et al, I am pleased that Alexey got a quick reply to his mailing, but it would be nice if someone could respond to the mail about the "oid:" URI/IRI scheme that was posted on 18 November. Thanks John L Bjoern Hoehrmann wrote:

Re: Request to review sieve URI scheme

Bjoern Hoehrmann — 2008-11-30T19:33:10

You have a reference [IMAP4] but it's not part of the References in the document. I assume this should be [IMAP4rev1]. You should say upfront that `authority`, `unreserved`, etc. are defined in STD066 and included by reference. Right now you are using authority without defining it, and repeat the reference multiple times. There is not much point in having the sub-delims-sh and uchar rules in the grammar, you could just use ochar = " That way readers would not have to read through the comments and expand the rules manually. The difference between sieve://example/script (owner absent) sieve://example//script (owner empty) should be explicitly called out somewhere. It would be better if this is done outside the grammar (the semantics of having an empty owner would also be b

Request to review sieve URI scheme

Alexey Melnikov — 2008-11-30T17:56:41

Hi, I am finishing draft-ietf-sieve-managesieve-02.txt which defines the sieve: URI scheme. So I would like to ask people to review section 3 of the draft. Thank you, Alexey

New Internet Draft for your review

John Larmouth — 2008-11-18T10:53:35

All, I would be grateful if you could review the draft at http://www.ietf.org/internet-drafts/draft-larmouth-oid-iri-00.txt This is the first step in a hoped-for IANA registration of the oid IRI scheme. Thanks. John L

Update to the URI draft

Eric Johnson — 2008-11-18T04:57:22

Now found here: http://www.ietf.org/internet-drafts/draft-merrick-jms-uri-05.txt Feedback welcome! -Eric.

Re: New version of JMS URI posted.

Eric Johnson — 2008-10-31T22:03:46

Hi Mark, Mark Baker wrote: I have saved all that mail from that time period as well, and I have your questions. Seeing as you don't specifically call out the questions you have that might remain, that makes it a little difficult for me to intuit exactly which issues we have that might be outstanding. If you could restate precisely your concerns, that would be most helpful. In the last email on the thread, I see this from you: MB >>>>>> When I looked at the JMS spec, what I found was these; http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/ConnectionFactory.html http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/Destination.html Is that what you meant? <<<<<< MB Seeing as the first sentence of the introduction to the draft proposal now reads: " The "jms" URI scheme is used to designate a javax.jms.Destination object and an associated javax.jms.ConnectionFactory object, and optionally provide additional information concerning the way that the Destination object is to be

Re: New version of JMS URI posted.

Mark Baker — 2008-10-29T13:59:26

Eric - I'm unable to identify any portion of this new draft that addresses any of the previous concerns I've raised. Unfortunately it appears that the uri-review archives are broken, as this message of yours is the only one present, so I can't easily point you at them. But from my email archives, this was the discussion we had between Feb 15 and Mar 3 of this year concerning the meaning of "operations" and of what a jms URI actually identifies. Mark. On Mon, Oct 13, 2008 at 6:35 PM, Eric Johnson tibco.com> wrote:

New version of JMS URI posted.

Eric Johnson — 2008-10-13T22:35:48

http://www.ietf.org/internet-drafts/draft-merrick-jms-uri-04.txt Changes to this draft are discussed here: http://lists.w3.org/Archives/Public/public-soap-jms/2008Sep/0046.html http://lists.w3.org/Archives/Public/public-soap-jms/2008Oct/0018.html Please advise with any feedback you might have. Thanks! -Eric.

For review: the historical "videotex" URI scheme

Frank Ellermann — 2008-04-30T01:29:23

[repost - the article didn't make it in the archive: ] ----------------------------------------------------- URI scheme name: videotex Status: historical URI scheme syntax: "videotex://" login [ "/" videotexservice *[ parameter ] ] For details see the historical reference, a was in essence what STD 66 specifies as . URI scheme semantics: For details see the historical reference, the default port assigned by IANA is 516. For a rough idea "videotex" was an URI scheme in the direction of "tn3270" and "telnet". The "vemmi" URL scheme specified in RFC 2122 for port 575 was apparently designed to obsolete "videotex" URLs. Encoding considerations: The historical reference does not go into details. Picking an $EMULATION included values CEPT1 (BTX), CEPT2 (Teletel latin mode), CEPT2GREEK (Teletel greek mode), CEPT2ARABIC, CEPT3 (Prestel), CEPT4, NAPLPS, CAPTAIN, VT52, VT100, VT220, and a way for serve

Re: URI Review for HELDS URI

Frank Ellermann — 2008-04-23T22:06:30

Hi, I tried to understand what this memo does. == namespace == In 12.1 it creates an URN for the namespace, specifying a (minimal) XHTML page in the XML section of the registration template. Apparently IANA does not use this as intended, they publish the complete templates as text: http://www.iana.org/assignments/xml-registry/ns/common-policy.txt http://www.iana.org/assignments/xml-registry/ns/contact-1.0.txt The latter says "XML: None. Namespace URIs do not represent an XML specification." In some cases there are no templates at all, examples: urn:ietf:params:xml:ns:asnx urn:ietf:params:xml:ns:caldav If the whole point of this exercise is to get a row in in the namespace table, then the 4th column already is a pointer to the reference, and IANA doesn't support the creation of XHTML pages of registration templates in the third column. == schema == Apparently chapter 7 could be merged into 12.2. If BEGIN and END in chapter 12.1 help, then it might also help in chapter 7 (?)

URI Review for HELDS URI

Cullen Jennings — 2008-04-23T18:35:05

The following ID contains a new URI scheme: http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-07 Could folks please review this and sends comments before May 18th. Thanks, Cullen

draft-merrick-jms-uri-03 - requesting comments on new version of JMS URI scheme

Eric Johnson — 2008-04-22T18:00:40

Having received feedback that we needed to address the operations on the URI scheme, and that we got the ABNF grammar and reference wrong (it has been updated), we have made changes that we believe address the open concerns. Comments welcome: https://datatracker.ietf.org/drafts/draft-merrick-jms-uri/ -Eric.

Re: Review:: draft-shur-pack-uri-scheme

Frank Ellermann — 2008-04-07T18:43:30

Yes, it cannot match a without "< at >". The right hand side does not match , it is no URI. Pseudo-URIs caused enough havoc in 2007 on a popular platform where ECMA 376 might be used if implemented. Frank

Re: [rfc-i] Review:: draft-shur-pack-uri-scheme

Graham Klyne — 2008-04-07T09:05:32

Not only confusing, but contravening the requirements for registering a new URI scheme. See: http://www.rfc-editor.org/rfc/rfc4395.txt sections 2.8, 3. The examples in section 3.2 of http://tools.ietf.org/id/draft-shur-pack-uri-scheme-03.txt are not allowable according to the syntax defined in http://www.ietf.org/rfc/rfc3986.txt (only digits may follow a ':'). #g

Re: draft-merrick-jms-uri-01.txt

Mark Baker — 2008-03-03T16:17:59

Hi Eric, On Fri, Feb 29, 2008 at 2:28 PM, Eric Johnson tibco.com> wrote: When I looked at the JMS spec, what I found was these; http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/ConnectionFactory.html http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/Destination.html Is that what you meant? AFAICT, those are just local programmatic operations, not remote ones, no? Sure. But which exactly part of the spec are you referencing (if not what I reference above)? Thanks. Mark.

Re: draft-merrick-jms-uri-01.txt

Eric Johnson — 2008-02-29T19:28:50

Hi Mark, Mark Baker wrote: Hmmm. Now I cannot figure out whether there are *additional* terms we somehow don't agree on. In the email that lead to this thread, we suggested a further revision to our 01 revision of the JMS URI scheme that includes the following text - text which unfortunately been dropped in the email exchanges leading to this one: "The operations which can be performed on the ConnectionFactory and Destination resources are defined by the JMS specification and so a detailed description is outside the scope of this specification, but a JMS application typically uses a ConnectionFactory to create a connection to a messaging provider, and sends and receives messages to and from Destinations." There it is - the available operations defined. What am I missing? Clearly it would be a mistake to inline the contents of a normative reference describing those references in detail, and the reference from the suggested text above is preferable, no? -Eric.

Re: draft-merrick-jms-uri-01.txt

Mark Baker — 2008-02-28T18:38:46

Hi, On 2/27/08, Eric Johnson tibco.com> wrote: Right. But it does ask what operations can be performed on the thing identified by the URI. I don't think that leaves much room for interpretation, whether or not you use the language "application layer operation". Avoiding "application layer" - sorry for muddying the waters with a confusing term - yes, the send operation is the kind of operation which should be documented with the registration. Do you mean that jms URIs all identify resources to which one can send data, ala email? If so, then that's what you should document. Mark.