- ogsa-wg - lists.ogf.org

BT Messaging Anti-Virus Alert
by bt.email.antivirus＠bt.com 24 Nov '05

24 Nov '05

Notification Of Blocked e-mail - This message is intended for BT employees only. All other recipients: Please ignore this message and accept our apology for any inconvenience (N.B. the links below are private). An e-mail (summarised below) has been blocked at the BT e-mail gateway because it contained an attachment of a potentially dangerous type <http://teamconnect.intra.bt.com/pas/m/email/antivirus/blocked.htm> or a computer virus. Date/Time: "24 Nov 2005 03:41:26" From: "Symantec_AntiVirus_for_SMTP_Gateways(a)capitolindemnity.com" Subject: "Returned mail" Blocked file: "mailtext.zip" Virus Name: "Sober.dam" BT Employees: If there is a legitimate business requirement for this e-mail, please ask the originator to re-send it. You must advise them to follow the special instructions, which you will find at this location <http://antivirus.intra.bt.com/zippass.htm> for re-sending e-mail of this type. They should also ensure that the e-mail is virus-free. More information on blocked attachments can be found at http://teamconnect.intra.bt.com/pas/m/email/antivirus/blocked.htm <http://teamconnect.intra.bt.com/pas/m/email/antivirus/blocked.htm> Please do not reply to this email. Thank you. BT Teamconnect Enterprise Solutions British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. Generated by: C04

1 0

BT Messaging Anti-Virus Alert
by bt.email.antivirus＠bt.com 24 Nov '05

24 Nov '05

Notification Of Blocked e-mail - This message is intended for BT employees only. All other recipients: Please ignore this message and accept our apology for any inconvenience (N.B. the links below are private). An e-mail (summarised below) has been blocked at the BT e-mail gateway because it contained an attachment of a potentially dangerous type <http://teamconnect.intra.bt.com/pas/m/email/antivirus/blocked.htm> or a computer virus. Date/Time: "24 Nov 2005 03:41:19" From: "Symantec_AntiVirus_for_SMTP_Gateways(a)capitolindemnity.com" Subject: "Returned mail" Blocked file: "mailtext.zip" Virus Name: "Sober.dam" BT Employees: If there is a legitimate business requirement for this e-mail, please ask the originator to re-send it. You must advise them to follow the special instructions, which you will find at this location <http://antivirus.intra.bt.com/zippass.htm> for re-sending e-mail of this type. They should also ensure that the e-mail is virus-free. More information on blocked attachments can be found at http://teamconnect.intra.bt.com/pas/m/email/antivirus/blocked.htm <http://teamconnect.intra.bt.com/pas/m/email/antivirus/blocked.htm> Please do not reply to this email. Thank you. BT Teamconnect Enterprise Solutions British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. Generated by: C02

1 0

Returned mail
by Symantec_AntiVirus_for_SMTP_Gateways＠capitolindemnity.com 24 Nov '05

24 Nov '05

--- The message cannot be delivered to the following address. --- register(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <register(a)capitolindemnity.com>: Recipient address rejected: No such user (register(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- kkeating(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <kkeating(a)capitolindemnity.com>: Recipient address rejected: No such user (kkeating(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- swreal(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <swreal(a)capitolindemnity.com>: Recipient address rejected: No such user (swreal(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- peter.belesis(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <peter.belesis(a)capitolindemnity.com>: Recipient address rejected: No such user (peter.belesis(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- Les.Hill(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <Les.Hill(a)capitolindemnity.com>: Recipient address rejected: No such user (les.hill(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- SenTStamas(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <SenTStamas(a)capitolindemnity.com>: Recipient address rejected: No such user (sentstamas(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- entertainment(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <entertainment(a)capitolindemnity.com>: Recipient address rejected: No such user (entertainment(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- vandenick(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <vandenick(a)capitolindemnity.com>: Recipient address rejected: No such user (vandenick(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- cleanearth(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <cleanearth(a)capitolindemnity.com>: Recipient address rejected: No such user (cleanearth(a)capitolindemnity.com)

1 0

Returned mail
by Symantec_AntiVirus_for_SMTP_Gateways＠capitolindemnity.com 24 Nov '05

24 Nov '05

--- The message cannot be delivered to the following address. --- dave(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <dave(a)capitolindemnity.com>: Recipient address rejected: No such user (dave(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- barbjanish(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <barbjanish(a)capitolindemnity.com>: Recipient address rejected: No such user (barbjanish(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- staff(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <staff(a)capitolindemnity.com>: Recipient address rejected: No such user (staff(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- kdettmer(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <kdettmer(a)capitolindemnity.com>: Recipient address rejected: No such user (kdettmer(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- artmp(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <artmp(a)capitolindemnity.com>: Recipient address rejected: No such user (artmp(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- rashah(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <rashah(a)capitolindemnity.com>: Recipient address rejected: No such user (rashah(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- elmbrook(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <elmbrook(a)capitolindemnity.com>: Recipient address rejected: No such user (elmbrook(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- peterbelesis(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <peterbelesis(a)capitolindemnity.com>: Recipient address rejected: No such user (peterbelesis(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- Products(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <Products(a)capitolindemnity.com>: Recipient address rejected: No such user (products(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- dabeck(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <dabeck(a)capitolindemnity.com>: Recipient address rejected: No such user (dabeck(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- wine(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <wine(a)capitolindemnity.com>: Recipient address rejected: No such user (wine(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- AgamingGC(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <AgamingGC(a)capitolindemnity.com>: Recipient address rejected: No such user (agaminggc(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- amckenzie(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <amckenzie(a)capitolindemnity.com>: Recipient address rejected: No such user (amckenzie(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- ellislakeresort(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <ellislakeresort(a)capitolindemnity.com>: Recipient address rejected: No such user (ellislakeresort(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- one_spook(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <one_spook(a)capitolindemnity.com>: Recipient address rejected: No such user (one_spook(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- sharonsantorum(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <sharonsantorum(a)capitolindemnity.com>: Recipient address rejected: No such user (sharonsantorum(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- Manager(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <Manager(a)capitolindemnity.com>: Recipient address rejected: No such user (manager(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- Regs(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <Regs(a)capitolindemnity.com>: Recipient address rejected: No such user (regs(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- Wendy(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <Wendy(a)capitolindemnity.com>: Recipient address rejected: No such user (wendy(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- matthewgillard(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <matthewgillard(a)capitolindemnity.com>: Recipient address rejected: No such user (matthewgillard(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- treasupd(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <treasupd(a)capitolindemnity.com>: Recipient address rejected: No such user (treasupd(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- aking(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <aking(a)capitolindemnity.com>: Recipient address rejected: No such user (aking(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- sil(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <sil(a)capitolindemnity.com>: Recipient address rejected: No such user (sil(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- jackie(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <jackie(a)capitolindemnity.com>: Recipient address rejected: No such user (jackie(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- employment(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <employment(a)capitolindemnity.com>: Recipient address rejected: No such user (employment(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- realestateone(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <realestateone(a)capitolindemnity.com>: Recipient address rejected: No such user (realestateone(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- kb(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <kb(a)capitolindemnity.com>: Recipient address rejected: No such user (kb(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- wd(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <wd(a)capitolindemnity.com>: Recipient address rejected: No such user (wd(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- ebaysales(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <ebaysales(a)capitolindemnity.com>: Recipient address rejected: No such user (ebaysales(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- bknopp(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <bknopp(a)capitolindemnity.com>: Recipient address rejected: No such user (bknopp(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- free2rhyme(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <free2rhyme(a)capitolindemnity.com>: Recipient address rejected: No such user (free2rhyme(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- paul.abbott(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <paul.abbott(a)capitolindemnity.com>: Recipient address rejected: No such user (paul.abbott(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- gdiller(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <gdiller(a)capitolindemnity.com>: Recipient address rejected: No such user (gdiller(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- cgoeke(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <cgoeke(a)capitolindemnity.com>: Recipient address rejected: No such user (cgoeke(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- rrezac(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <rrezac(a)capitolindemnity.com>: Recipient address rejected: No such user (rrezac(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- abc(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <abc(a)capitolindemnity.com>: Recipient address rejected: No such user (abc(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- LoriL(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <LoriL(a)capitolindemnity.com>: Recipient address rejected: No such user (loril(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- DZeller(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <DZeller(a)capitolindemnity.com>: Recipient address rejected: No such user (dzeller(a)capitolindemnity.com) --- The message cannot be delivered to the following address. --- BGrant(a)capitolindemnity.com Mailbox unknown or not accepting mail. 550 <BGrant(a)capitolindemnity.com>: Recipient address rejected: No such user (bgrant(a)capitolindemnity.com)

1 0

Virus Found in message "hi ive a new mail address"
by Janice VanWagoner 23 Nov '05

23 Nov '05

Symantec AntiVirus found a virus in an attachment you (grdfm-ogsa-wg-outgoing(a)mailbouncer.mcs.anl.gov <grdfm-ogsa-wg-outgoing(a)mailbouncer.mcs.anl.gov>) sent to emailserv(a)tomia247.com. To ensure the recipient(s) are able to use the files you sent, perform a virus scan on your computer, clean any infected files, then resend this attachment. Attachment: mailtext.zip Virus name: Multiple viruses found. Please see individual log messages. Action taken: Quarantine succeeded : File status: Still contains 1 infected items

1 0

RE: [ogsa-wg] Once upon a time or two ...
by Dave Berry 23 Nov '05

23 Nov '05

There are many issues in this discussion that I don't understand , and this seems a key one. Perhaps the participants could read the following and set me straight? The W3C guidelines on the use of URIs (and hence, I presume, IRIs) is that each resource should be identified by a different URI. URIs can be compared. URIs should not be reused to refer to different resources. I don't know whether these guidelines are adhered to in practice, but on paper they seem to provide the uniqueness and comparison functionality that we require. The problem seems to be that WS-Addressing (or perhaps just some uses of it, e.g. some implementations of WSRF) breaks this nice system, by using the URI to name the access mechanism (the web service) rather than the resource being addressed. Frank has suggested on a couple of occasions that we specify how a unique address can be reconstructed from the wsa:to field and the parameters. Given this step, I would assume that the scenario that Frank considers here would not be permitted: > > An EPR-minter can decide to create a new EPR for a resource and reuse > > an Address that was used for an other resource before. So, I have many questions: 1. Is the above characterisation an accurate rendition of the W3C position on URIs and IRIs? 2. Do we want stricter limits than the W3C? 3. Can we profile WS-A as Frank suggests? 4. If (3 and not(2)), does that satisfy our requirements? Another advantage of URIs is that publishers are permitted to use their structure to pass back server-specified information and clients are permitted to parse URIs to extract this information. So an LSF system could include the job-id in a certain part of the URI and clients can extract it as necessary. (Although one could argue whether that was any neater than adding a specific XML field). Best wishes, Dave. > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On > Behalf Of David Snelling > Sent: 18 November 2005 15:12 > To: Frank Siebenlist > Cc: ogsa-wg; ogsa-naming-wg(a)ggf.org > Subject: [ogsa-wg] Once upon a time or two ... > > Folks, > > Once up on a time or two Frank wrote: > > > Without the proper uniqueness guarantees for the > wsa:Address, the use > > of ws-naming's AbstractName is meaningless. > > > > The EPR with an embedded AbstractName essentially describes > a binding > > between the Address and the AbstractName. > > One could argue that this binding is a bit of a flaky assertion > > without any way to specify time-validity or issuer. > > As a result, one can not see from an EPR alone when it was > issued or > > whether it is still valid or not. > > > > This would yield the undesirable situation that you would have two > > EPRs with identical Addresses and two different AbstractNames > > associated with different resources, and the client would > have no way > > to see which one of the EPRs is valid... > > > > For example, if I have two EPRs with the same Address, > where one EPR > > includes an AbstractName that identifies MyBankAccount and > the other > > includes an AbstractName identifying YourBankAccount, then > one of us > > will not be happy with that situation... > > > > In order to avoid this ambiguity, we need the guarantee from the > > EPR-minter that Address values will not be reused for different > > resources: for all times, the Address should either refer > to that one > > and only resource, or it should be invalid (and it is allowed to > > change between those two states). > > Furthermore, the EPR-minters should ensure that globally unique > > Addresses are used for a resource such that different > EPR-minters do > > not (accidentally) use the same Address for different resources. > > The described uniqueness properties of the Address constitutes a > > required EPR-minter profile for the use of AbstractNames. > > > > This issue has yet to be addressed to my satisfaction. There > have been > a number of email exchanges in response to it on several > occasions, but > none of these threads actually deal with the issue. > > Put simply, if you don't put globally-unique-in-space-time > requirements > on your address (GSR in OGSI speak*) then any similar > requirements you > put on an Abstract Name (GSH in OGSI speak) are wasted. > > I believe that answering this issue will help clarify many of > the other > threads (miss) associated with this issue. > > In particular, I believe Frank is right. Therefore, if an EPR > is going > to be a WS-Name, the wsa:Address MUST have the same uniqueness > properties as the Abstract Name. Then if the answer to the question, > "Why do this uniqueness stuff twice?", is "I don't know!", then it > seems logical to me that a WS-Name is a profiled EPR along the lines > proposed by Tom M. > > Thoughts? > > Historical Footnote: > > * Note: OGSI addressed this issue in GSRs by requiring that clients > could detect when the GSRs were stale and that services > reject them if > a client attempted to use them. GSHs had uniqueness > constraints placed > on them. > > -- > > Take care: > > Dr. David Snelling < David . Snelling . UK . Fujitsu . com > > Fujitsu Laboratories of Europe > Hayes Park Central > Hayes End Road > Hayes, Middlesex UB4 8FE > > +44-208-606-4649 (Office) > +44-208-606-4539 (Fax) > +44-7768-807526 (Mobile) > >

3 2

Data architecture requirements on naming
by Dave Berry 23 Nov '05

23 Nov '05

Dear All, Recent discussions on the OGSA data architecture have raised two use cases that may affect the naming discussion. Both involve the mapping of one "abstract" (for some meaning of "abstract") name to multiple possible "concrete" names. A further step is then required to choose the best "concrete" name, according to the policies required by the client. We are wondering whether the WS-Name/EPR resolution services can be modified to support these functionalities. Note: here, "abstract" names may or may not have the same meaning as abstract names in the proposed WS-Names spec. This is an issue that needs clarification. Case 1 is when we are dealing with replicated data. It is common to have an "abstract" name that represents a given file, table or query result that is stored someone in the system. This is then resolved to one of multiple copies. The client typically wants the copy with the best response time (which will be some function of latency and bandwidth). Case 2 is when we are dealing with data stored at a certain location and the data may be accessed by several different protocols (e.g. GridFTP, HTTP, ...). The client (or transfer service) wants to map the "abstract" name to the fastest protocol that it can handle. In each case, we could take one of two approaches: (A) resolve the "abstract" name to a list of "concrete" names, and use a separate selection service to choose among them (B) pass the appropriate policy specification to the resolver service, which will then return the appropriate "concrete" name. Note: (B) could be considered (and even implemented) as a composition of the resolver and selection services in (A). Would it make sense to specify either one of these functionalities as part of the resolver services considered in WS-Naming? E.g. the operations could return a list instead of a single EPR (option A) or they could return a single EPR as now but take a policy argument (option B). Best wishes, Dave Berry Research Manager, National e-Science Centre 15 South College St., Edinburgh Tel: +44 131 6514039

2 1

RE: [ogsa-d-wg] Data architecture requirements on naming
by Hiro Kishimoto 22 Nov '05

22 Nov '05

Peter's email bounced. -- Hiro Kishimoto Subject: RE: [ogsa-d-wg] Data architecture requirements on naming Date: Tue, 22 Nov 2005 13:36:31 +0100 From: "Peter Kunszt" <Peter.Kunszt(a)cern.ch> To: "David Berry" <daveb(a)nesc.ac.uk>, <ogsa-naming-wg(a)ggf.org>, "ogsa-wg" <ogsa-wg(a)gridforum.org>, <ogsa-d-wg(a)gridforum.org> hi dave in our experience, case (B) is not being used by clients. the reason is that the policies that are put in place to find the 'best' concrete replica are very application specific and are usually implemented by the applications themselves. what turned out to be much more useful was to present the list of replicas when asked for it with some measured qualifyers that the grid can provide, i.e. predicted access cost, latency, time to wait (queues) or whatever is available so that the application can resolve the 'best' replica based on any model/policy they may want to apply. it turned out that implementing a generic policy enforcer is very difficult and what you end up doing is to provide a python interpreter so that the applications can write their own policy scripts... hope this helps, cheers, peter >> -----Original Message----- >> From: owner-ogsa-d-wg(a)ggf.org >> [mailto:owner-ogsa-d-wg@ggf.org] On Behalf Of Dave Berry >> Sent: 22 November 2005 11:30 >> To: ogsa-naming-wg(a)ggf.org; ogsa-wg; ogsa-d-wg(a)gridforum.org >> Subject: [ogsa-d-wg] Data architecture requirements on naming >> >> Dear All, >> >> Recent discussions on the OGSA data architecture have raised >> two use cases that may affect the naming discussion. Both >> involve the mapping of one "abstract" (for some meaning of >> "abstract") name to multiple possible "concrete" names. A >> further step is then required to choose the best "concrete" >> name, according to the policies required by the client. We >> are wondering whether the WS-Name/EPR resolution services can >> be modified to support these functionalities. >> >> Note: here, "abstract" names may or may not have the same >> meaning as abstract names in the proposed WS-Names spec. >> This is an issue that needs clarification. >> >> Case 1 is when we are dealing with replicated data. It is >> common to have an "abstract" name that represents a given >> file, table or query result that is stored someone in the >> system. This is then resolved to one of multiple copies. >> The client typically wants the copy with the best response >> time (which will be some function of latency and bandwidth). >> >> Case 2 is when we are dealing with data stored at a certain >> location and the data may be accessed by several different >> protocols (e.g. GridFTP, HTTP, ...). The client (or transfer >> service) wants to map the "abstract" name to the fastest >> protocol that it can handle. >> >> In each case, we could take one of two approaches: >> >> (A) resolve the "abstract" name to a list of "concrete" >> names, and use a separate selection service to choose among them >> >> (B) pass the appropriate policy specification to the resolver >> service, which will then return the appropriate "concrete" name. >> >> Note: (B) could be considered (and even implemented) as a >> composition of the resolver and selection services in (A). >> >> Would it make sense to specify either one of these >> functionalities as part of the resolver services considered >> in WS-Naming? E.g. the operations could return a list >> instead of a single EPR (option A) or they could return a >> single EPR as now but take a policy argument (option B). >> >> Best wishes, >> >> Dave Berry >> Research Manager, National e-Science Centre >> 15 South College St., Edinburgh >> Tel: +44 131 6514039

1 0

Re: latest ws-naming draft (Re: [ogsa-naming-wg] One more thing)
by Mark McKeown 22 Nov '05

22 Nov '05

Hi Frank, I have made some comments inline... First to remove some confusion about IRIs that have appeared in previous mails in this thread. URNs and URLs are URIs[1], IRIs[2] are an extension of URIs to support extra charactors. A URI may or may not map to a real physical address. The WS-Addressing specification[3] defines a number of URIs that do not map to real network locations (eg http://www.w3.org/2005/08/addressing/anonymous) WS-Addressing mandates that the wsa:Address element is an absolute IRI. > > * include a profile for the use of the Address and ReferenceParameters > that ensure the proper uniqueness property in time and space of the > reference. Tom Maguire suggested to use the wsdl binding of the address > which sounded very promising. I am not sure I have understood Tom's argument correctly so I will try and repeat it here in order to be corrected... TomM suggested using the wsa::Address as the name, I understand his argument as being that with the WSDL binding for WS-Addressing you can include the service part of the WSDL into the wsa:Metadata of the EPR, the service part may contain a number of network endpoints indicating that the WS-Resource is available at a number of locations. >From 'Web Services Addressing 1.0 - WSDL Binding' [4]: "In particular, embedding a WSDL service component description MAY be used by EPR issuers to indicate the presence of alternative addresses and protocol bindings to access the referenced endpoint." In this case the wsa:Address could be a URN (or URI that is not an actual network location) and the client could look to the wsa:Metadata to find the actual network location of the WS-Resource. Quoting Tom[5]: "Let me be very clear about this an EPR does not have a 1 to 1 correspondence with a protocol and binding address. It MUST be true that an EPR can support multiple protocols and their associated addresses." I am not sure I agree, the WS-Addressing WSDL binding uses "MAY" when discussing including WSDL components in the EPR, there is no obligation. I think most services will only use one transport protocol so I think this feature will not be used often - even if a service does use more than one transport/port there is no requirement to advertise this in the EPR. Also there is no transport bindings available for WS-Addressing - for example the SOAP bindings tells us to take the wsa:Address element and put it into the wsa:To element in the SOAP header but does not tell us what to do with it with regards to the transport protocol (eg most people use the wsa:Address element to create a RequestURI which they set as the POST HTTP Header when using HTTP - this issue has been raised with the W3C TAG[6]). Quoting WS-Addressing: "A Web service endpoint is a (referenceable) entity, processor, or resource to which Web service messages can be addressed. Endpoint references convey the information needed to address a Web service endpoint." To me there is a strong emphasis on singlar. > > * include a recipe for generation of a single IRI from the Address and > ReferenceParameters that can function as an identifier of the resource. > Mark Mc Keown pointed at the W3C Web Architecture description of the use > of URIs which we could borrow from. I am not sure about creating an IRI from the wsa:Address and the wsa:ReferenceParameters. Consider the following EPRs <wsa:EndPointReference> <wsa:Address>http://grid.org/jobs/4654</wsa:Address> <wsa:ReferenceParameters> <DateCreated>Thu Nov 17 16:05:43 UTC 2005</DateCreated> </wsa:ReferenceParameters> </wsa:EndPointReference> and <wsa:EndPointReference> <wsa:Address>http://grid.org/jobs/4654</wsa:Address> <wsa:ReferenceParameters> <DateCreated>Thu Nov 17 13:07:53 UTC 2005</DateCreated> </wsa:ReferenceParameters> </wsa:EndPointReference> If DateCreated is just to inform the service when the EPR was created and is not used by the service for anything else then the two EPRs are for the same WS-Resource. However if I create a name based on a combination of the wsa:Address and wsa:ReferenceParameters I will get two different names, ie I have created URI aliases and divided the network losing some of the goodness of Metcalfes law [7]. cheers Mark [1] http://www.ietf.org/rfc/rfc2396.txt [2] http://www.ietf.org/rfc/rfc3987.txt [3] http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/ [4] http://www.w3.org/TR/2005/WD-ws-addr-wsdl-20050413/ [5] http://www-unix.gridforum.org/mail_archive/ogsa-naming-wg/2005/11/msg00021.… [6] http://www.w3.org/2001/tag/issues.html#endPointRefs-47 [7] http://www.w3.org/TR/webarch/

2 1

Proposal to split "Secure channel" profile
by Andreas Savva 22 Nov '05

22 Nov '05

During the review of the "Basic Security Profile - Secure Channel" today it was pointed out that Section 3.4 (Security Token), Section 4 (SAML Token Profile 1.0) and Appendix D (Key Information Exchange) are 'more basic' than the other parts of the profile and that it would be worth splitting them off in a separate document. Doing so would allow other future security profiles (e.g., an MLS profile) to use these sections without creating unnecessary dependencies with the Secure Channel (TLS) profile. Therefore the proposal is to separate these sections in an "OGSA Basic Security Profile" document. This document would expose the claim required to satisfy the WSRF BP security profile requirements (http://www.ggf.org/namespaces/2005/07/OGSABasicSecurity-1.0) but would have no normative dependency on the WSRF BP. In addition it was proposed that this profile would have explanatory text stating that it is defining an 'anonymous channel' (one requiring no security or authentication for service interaction) and would also expose the following claim: http://www.ggf.org/namespaces/2005/11/OGSABasicSecurityProfile-1.0-Anonymou… (This second proposal is optional and is primarily to reduce the number of security profiles we have to write.) The "Secure Channel" profile will then reference the "OGSA Basic Security Profile" and will expose in turn the following conformance claims: http://www.ggf.org/namespaces/2005/07/OGSABasicSecurity-1.0 (as required for composition with the WSRF BP) and http://www.ggf.org/namespaces/2005/08/OGSABasicSecurityProfile-1.0-SecureCh… Comments on the list, or please join next Monday's call where this proposal is scheduled to be discussed. Andreas >From the minutes: > - 1698: Strictly speaking the features described in section 3.4 and > section 4 are orthogonal to the rest of the profile. Tokens, and > the key exchange mini-specification would apply to both TLS and > MLS. > - If this text is left here then the MLS profile would have to > depend on this profile; or worse, duplicate the same text. > - Frank proposed that if these sections are needed in general then > it might be worth deleting these sections from the Secure > Channel Profiel and adding them to the WSRF Basic Profile. > - Agreed, in principle, to remove the sections from this spec. and > discuss how to make them apply to any profile. > - Andreas proposed that these sections should be part of a Basic > Security Profile and that Profile could then be combined with > the WSRF BP or be referenced by the Channel profiles. The Claim > URI mechanism defined in the WSRF BP allows multiple Security > profiles to be composed with it so there would be no problem > with this approach. > - Hiro proposed that such a Basic Security Profile could also > serve as an 'anonymous' channel profile (one that makes no > statements on channel security) and could also solve the problem > of having a separate, essentially empty, profile document with > no security statements. > - Andreas was tasked to write up the proposal for splitting up the > Secure Channel Profile and send it to the list to collect > feedback from stakeholders not on the call. -- Andreas Savva Fujitsu Laboratories Ltd

1 0