-----Original Message----- From: owner-ogsa-bes-wg@ggf.org [mailto:owner-ogsa-bes-wg@ggf.org] Sent: Thursday, November 10, 2005 2:47 PM To: owner-ogsa-bes-wg@ggf.org Subject: BOUNCE ogsa-bes-wg@ggf.org: Non-member submission from [itf@mcs.anl.gov]

From owner-grdfm-ogsa-bes-wg@mailbouncer.mcs.anl.gov Thu Nov 10 15:47:13 2005 Return-Path: X-Original-To: grdfm-ogsa-bes-wg@mailbouncer.mcs.anl.gov Delivered-To: grdfm-ogsa-bes-wg@mailbouncer.mcs.anl.gov Received: from localhost (localhost [127.0.0.1]) by mailbouncer.mcs.anl.gov (Postfix) with ESMTP id 83F5112C96; Thu, 10 Nov 2005 15:47:13 -0600 (CST) Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by mailbouncer.mcs.anl.gov (Postfix) with ESMTP id 1592112C94; Thu, 10 Nov 2005 15:47:12 -0600 (CST) Received: from www-unix.mcs.anl.gov (gust.mcs.anl.gov [140.221.9.215]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id jAALkqQ14270; Thu, 10 Nov 2005 15:46:52 -0600 Received: from 208.54.72.239 (SquirrelMail authenticated user itf) by www-unix.mcs.anl.gov with HTTP; Thu, 10 Nov 2005 15:46:52 -0600 (CST) Message-ID: <1472.208.54.72.239.1131659212.squirrel@www-unix.mcs.anl.gov> In-Reply-To: <43739301.7080507@mcs.anl.gov> References: <20051110143143.H67244-100000@nessie.mcc.ac.uk> <43739301.7080507@mcs.anl.gov> Date: Thu, 10 Nov 2005 15:46:52 -0600 (CST) Subject: Re: [ogsa-naming-wg] Re: [ogsa-wg] Abstract names in BES From: itf@mcs.anl.gov To: "Frank Siebenlist" Cc: "Mark McKeown" , "Donal K. Fellows" , ogsa-wg@ggf.org, ogsa-naming-wg@ggf.org, ogsa-bes-wg@ggf.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mailbouncer.mcs.anl.gov X-Spam-Status: No, hits=-0.8 tagged_above=-1.0 required=5.0 tests=AWL, BAYES_00, NO_REAL_NAME X-Spam-Level:

Mark McKeown wrote:

...

Hi Donal,

...

...

Regarding Chris's desire to be able to pass the LSF jobid back to the client somehow - it could be included in the EPR's Metdata, possibly RDF could be used to mark up the Metadata to indicate that it is a LSF jobid. In this way the Address IRI can be kept opaque.

That would seem to me to be needless disambiguation. Surely it is just up to the service that mints the abstract name to understand it;

I'm concerned that the following two notions may be inconsistent: a) WS-Names should be globally unique (Andrew) b) The WS-Name can be used to pass a LSF jobid (Chris) Or is Chris proposing that LSF be changed to generate its jobids with whatever scheme WS-Naming proposes to ensure global uniqueness? (If it doesn't, then I don't think that Chris can guarantee that the names that LSF generates and the names that someone else generates will not collide.) Ian. there

...

...

is no inherent need for it to explain what that means to anyone else.

I am not sure I understand your comment - you don't seem to be disagreeing with me...

Frank wants to use the EPR's wsa:Address IRI as an AbstractName, Chris wants to send a LSF jobid to the client and the W3C recommends that IRIs should be opaque. One way to include the LSF jobid in the EPR is to embed it into the wsa:Address IRI, this might help make it unique and the client could extract it from the IRI - however the W3C recommends that IRIs should be opaque.

Well, I also believe that it's better to keep the IRIs opaque and was suggesting to use the complete IRI itself as an alternative jobId.

Whether that could work depends on the use cases we have to consider...

-Frank.

-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory