Re: Fwd: Lars Eggert's No Objection on draft-merrick-jms-uri-11: (with COMMENT)

+1

____________________________________________________
Phil Adams 
Engineering Manager, WebSphere Lombardi Edition Development
IBM Austin, TX
email: phil_adams@us.ibm.com
office: (512) 286-5041  (tie-line 363-5041)
cell: (512) 750-6599




From:
Eric Johnson <eric@tibco.com>
To:
SOAP-JMS <public-soap-jms@w3.org>, Peter Easton <peaston@progress.com>
Date:
01/19/2011 12:43 PM
Subject:
Fwd: Lars Eggert's No Objection on draft-merrick-jms-uri-11: (with 
COMMENT)
Sent by:
public-soap-jms-request@w3.org



I'm thinking of addressing the concern raised below with the following two 
sentences to replace the one we have:

The syntax of this 'jms' URI is not compatible with previously existing, 
but unregistered 'jms' URI schemes.  However, the expressiveness of the 
scheme described herein should satisfy the requirements of all existing 
circumstances.

Comments?

-Eric.

-------- Original Message -------- 
Subject: 
Lars Eggert's No Objection on draft-merrick-jms-uri-11: (with COMMENT)
Date: 
Mon, 17 Jan 2011 02:09:35 -0800
From: 
Lars Eggert <lars.eggert@nokia.com>
To: 
The IESG <iesg@ietf.org>
CC: 
eric@tibco.com, peaston@progress.com, derek.rokicki@softwareag.com, 
m8philli@uk.ibm.com, draft-merrick-jms-uri@tools.ietf.org


Lars Eggert has entered the following ballot position for
draft-merrick-jms-uri-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

INTRODUCTION, paragraph 4:
>    The syntax of this 'jms' URI is not compatible with any known current
>    vendor implementation, but the expressivity of the format should
>    permit all vendors to use it.

  So are there vendor implementations of 'jms' already? If yes, what it
  the value in publishing a specification that is not compatible with
  any of them? Or do we have an indication that the vendors will adopt
  this spec?