Hi Aleksandr,

-IMO the real question is what such EPRs may be used for. If they planned as -replacements for URLs and *full* such EPR is going to be put into -every SOAP header then I would vote strongly against. But if such EPR is just a way -to describe service (same as corresponding section in Glue -document) and are ony meant to be used in some kind of information system/port -then why not.

------Original Message----- -From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of -Aleksandr Konstantinov -Sent: Friday, March 20, 2009 9:10 AM -To: pgi-wg@ogf.org -Subject: Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman) - -On Friday 20 March 2009 02:42, m.riedel@fz-juelich.de wrote: -> Hi security folks, -> -> in preparation of tomorrow I scanned the WS-Naming spec (GFD109) since

-was an optional (MAY) dependency in the strawman doc of it. -> -> ### Goal: -> -> (a) -> We are discussing the WS-Naming specification... -> -> (b) -> ... because we want to survey what's is adoption status is in production setups is -and what impacts might occur when implementing it... -> -> (c) -> ... in order to find out if the WS-Naming dependency makes sense for PGI in -general and for our security setup in particular. -> -> -> ### Bottom line of spec contents -> -> # Defines an Endpoint Identifier Profile -> WS-A add-ons -> # WS Address Endpoint identifier Profile -> WS-A add-ons -> # Endpoint Resolvers Profiles -> portType -> -> -> ### Possible Conclusions: -> -> # (A) As discussed earlier, this is yet another profile that increases

-EPR significantly -> while one spec adoption might not be critical, adopting WS- -Naming together with OGF Sec Addressing and VO lists in WS-MetaData elements -of EPRs might be together a 'just too big' EPR to be realistic - apart from the -functionality of the necessary resolvers in particular for WS-Naming. Bottom line: -Too much for the EPR - rather covered by an appropriate information service - - -IMO the real question is what such EPRs may be used for. If they planned as -replacements for URLs and *full* such EPR is going to be put into -every SOAP header then I would vote strongly against. But if such EPR is just a way -to describe service (same as corresponding section in Glue -document) and are ony meant to be used in some kind of information system/port -then why not. - -> -> -> ### Questions: -> -> # (A) Which middleware platform is adopting it currently and has precise

-adopt it in the near future. We can list for now GENESIS-II adopting it while I know -that UNICORE does not and has no precise plans for it now - what about others like -gLite, ARC, or NAREGI? - -ARC adopted EPR in development trunk but not using it for anything more

-enhanced URL. We currently have no plans to adopt it for any other

Just for clarification: With URLs you refer to the wsa:To element of WS-Addressing correct? If so, they are of course in any SOAP message - or I didn't get your point. Also, if it would be only to put into a kind of information system I would vote for crunching the EPR in elements that can be probably better searched for by an query instead of putting information into EPR. Here, WS-Naming, provides basically a name of a service while its EPR might change over time (renewable reference). Also the document refers to trackability of messages once you use WS-Naming (e.g. UUID dependency) - so I expect that this information of WS-Naming EPR additions should be part of any SOAP message. But that's only my interpretation from the document. Q: Can we agree that each functional service in the EPR space such as OGSA-BES are contacted with an pure EPR using URIs? We don't consider accessing a BESService simply with an URI - or do we? I would not vote for that. Take care, Morris there the size of an plans to than purposes.

- -> -> # (B) Is GLUE covering partly the information of getting endpoints for unique -names or something similiar like renewable references? -> -> -> The discussion before the TelCon might increase our progress... -> -> -> Your co-chair, -> Morris -> -> -> ->

----

-> Morris Riedel -> SW - Engineer -> Distributed Systems and Grid Computing Division -> Central Institute of Applied Mathematics -> Research Centre Juelich -> Wilhelm-Johnen-Str. 1 -> D - 52425 Juelich -> Germany -> -> Email: m.riedel@fz-juelich.de -> Info: http://www.fz-juelich.de/zam/ZAMPeople/riedel -> -> Phone: +49 2461 61 - 3651 -> Fax: +49 2461 61 - 6656 -> -> Skype: MorrisRiedel -> -> 'We work to improve ourselves and the rest of mankind.' -> -> -> -> ------------------------------------------------------------------- -> ------------------------------------------------------------------- -> Forschungszentrum Juelich GmbH -> 52425 Juelich -> -> Sitz der Gesellschaft: Juelich -> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 -> Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe -> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), -> Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, -> Dr. Sebastian M. Schmidt -> ------------------------------------------------------------------- -> ------------------------------------------------------------------- -> _______________________________________________ -> Pgi-wg mailing list -> Pgi-wg@ogf.org -> http://www.ogf.org/mailman/listinfo/pgi-wg -> -_______________________________________________ -Pgi-wg mailing list -Pgi-wg@ogf.org -http://www.ogf.org/mailman/listinfo/pgi-wg