November 2005 - ogsa-wg - lists.ogf.org

[ogsa-wg | Secure Channel 1.0 - 1698] - R0321: Is this compliance statement needed? It seems MLS related
by Sourceforge Tracker Monitor 16 Nov '05

16 Nov '05

A new artifact has been added: 1698 Submitted by: Takuya Mori Submitted date: 2005-11-17 02:13:34 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1698&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1698&group_id…) Summary: - R0321: Is this compliance statement needed? It seems MLS related Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1698 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-11-17 02:13:34 Submitted By: Takuya Mori Submit Date: 2005-11-17 02:13:34 Assigned To: &lt;None&gt; File(s): <None> Description: - R0321: Is this compliance statement needed? It seems MLS related and not needed by TLS. View the Secure Channel 1.0 : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Secure Channel 1.0 - 1697] Line 105: Add key info exchange to the list
by Sourceforge Tracker Monitor 16 Nov '05

16 Nov '05

A new artifact has been added: 1697 Submitted by: Takuya Mori Submitted date: 2005-11-17 02:08:38 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1697&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1697&group_id…) Summary: Line 105: Add key info exchange to the list Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1697 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-11-17 02:08:38 Submitted By: Takuya Mori Submit Date: 2005-11-17 02:08:38 Assigned To: &lt;None&gt; File(s): <None> Description: - Line 105: Add key info exchange to the list - Also since secure channel is defined further up try to use similar terminology here to make clearer what is being addressed by the profile. View the Secure Channel 1.0 : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

Common UML tool selection
by Hiro Kishimoto 16 Nov '05

16 Nov '05

Hi all, At November 14th tele-conference, OGSA-WG reviewed Mike's excellent UML tool survey. http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/11/msg00053.html Attendees for this call thought Rational is the best among others. > - Preference on the call for Rational. It is a full featured, > unlimited, version. It has support for all the features needed and > performance is good. Finally IBM's standards license should give > all GGF participants access to same version at no extra cost. I want to make a final decision on the next Monday call. Please post your comments and preference to the list before Monday. Thanks, -- Hiro Kishimoto From telecon minutes; > * UML tool selection > > Michael reviewed a number of UML tools and prepared a summary that > was sent to the list before the call. > http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/11/msg00053.html > > ** Requirements > - Generating code is not a strong requirement for OGSA at this time. > - Importing/exporting XMI from other tools probably falls in the > nice-to-have category. (But Michael clarified that sometimes even > importing portions of diagrams prepared by someone else using the > same tool caused problems.) > - Community or free editions of some commercial tools often add > banner text on printouts. It should count against that tool. > - Since the tools must be free other tools such as MS Visio are not > reviewed. > > ** Tool summary > - Poseidon: Very slow starting up---when clicking on a project icon > it took about 45sec to start up. But after that is quite usable > and the functionality is good. > - Rose: A big download but the functionality and performance is > good. A lot of features. But there are many editions and the RSM > version may be sufficient. > - It took about 1 week for a reply to the GGF license request. And > Michael still has to talk with someone at IBM about receiving a > license. > - Jude: Also quite good, but would need the Pro version (not free) > for import/export. > - Visual Paradigm was also quite good. > > ** Discussion > > - Preference on the call for Rational. It is a full featured, > unlimited, version. It has support for all the features needed and > performance is good. Finally IBM's standards license should give > all GGF participants access to same version at no extra cost. > - In the case of DMTF there is a designated IBM representative > within DMTF that participants can apply to and get a license. A > similar arrangements should be possible within GGF. > > Action: Ellen will check who can be IBM's contact within GGF > for Rational licenses. (It is probably going to be one of > Dave Martin or Jay Unger.) > > Action: Hiro will send out a short memo on the rough consensus to > the list. Ask for comments and make a final decision on the > next call.

1 0

RE: [ogsa-wg] Re: [ogsa-naming-wg] ... without wsa:Address profil e, AbstractName is meaningless ...
by Maguire_Tom＠emc.com 16 Nov '05

16 Nov '05

>And if so, is everyone expected to (a) have read and understood >section 3.2.3. on the subject of URI equivalence(below), or (b) >to explicitly require case-sensitive-string-matching as the comparison. I think logically (a) but since they SHOULD be IRIs I would use section 5 of RFC 3987 (below). Which basically adds codepoint normalization to the URI normalization you ref'd in section 3.2.3. The point being that we should be EXCEPTIONALLY clear about what it means to be equivalent. Perhaps we should even right a few TEST CASES. :-) Tom ---------------------------------------------------------------------------- --------------------- 5. Normalization and Comparison Note: The structure and much of the material for this section is taken from section 6 of [RFC3986]; the differences are due to the specifics of IRIs. One of the most common operations on IRIs is simple comparison: Determining whether two IRIs are equivalent without using the IRIs or the mapped URIs to access their respective resource(s). A comparison is performed whenever a response cache is accessed, a browser checks its history to color a link, or an XML parser processes tags within a namespace. Extensive normalization prior to comparison of IRIs may be used by spiders and indexing engines to prune a search space or reduce duplication of request actions and response storage. IRI comparison is performed for some particular purpose. Protocols or implementations that compare IRIs for different purposes will often be subject to differing design trade-offs in regards to how much effort should be spent in reducing aliased identifiers. This section describes various methods that may be used to compare IRIs, the trade-offs between them, and the types of applications that might use them. 5.1. Equivalence Because IRIs exist to identify resources, presumably they should be considered equivalent when they identify the same resource. However, this definition of equivalence is not of much practical use, as there is no way for an implementation to compare two resources unless it has full knowledge or control of them. For this reason, determination of equivalence or difference of IRIs is based on string comparison, perhaps augmented by reference to additional rules provided by URI scheme definitions. We use the terms "different" and "equivalent" to describe the possible outcomes of such comparisons, but there are many application-dependent versions of equivalence. Even though it is possible to determine that two IRIs are equivalent, IRI comparison is not sufficient to determine whether two IRIs identify different resources. For example, an owner of two different domain names could decide to serve the same resource from both, resulting in two different IRIs. Therefore, comparison methods are designed to minimize false negatives while strictly avoiding false positives. In testing for equivalence, applications should not directly compare relative references; the references should be converted to their respective target IRIs before comparison. When IRIs are compared to select (or avoid) a network action, such as retrieval of a representation, fragment components (if any) should be excluded from the comparison. Applications using IRIs as identity tokens with no relationship to a protocol MUST use the Simple String Comparison (see section 5.3.1). All other applications MUST select one of the comparison practices from the Comparison Ladder (see section 5.3 or, after IRI-to-URI conversion, select one of the comparison practices from the URI comparison ladder in [RFC3986], section 6.2) 5.2. Preparation for Comparison Any kind of IRI comparison REQUIRES that all escapings or encodings in the protocol or format that carries an IRI are resolved. This is usually done when the protocol or format is parsed. Examples of such escapings or encodings are entities and numeric character references in [HTML4] and [XML1]. As an example, "http://example.org/rosé" (in HTML), "http://example.org/ros&#233"; (in HTML or XML), and "http://example.org/ros&#xE9"; (in HTML or XML) are all resolved into what is denoted in this document (see section 1.4) as "http://example.org/ros&#xE9"; (the "é" here standing for the actual e-acute character, to compensate for the fact that this document cannot contain non-ASCII characters). Similar considerations apply to encodings such as Transfer Codings in HTTP (see [RFC2616]) and Content Transfer Encodings in MIME ([RFC2045]), although in these cases, the encoding is based not on characters but on octets, and additional care is required to make sure that characters, and not just arbitrary octets, are compared (see section 5.3.1). 5.3. Comparison Ladder In practice, a variety of methods are used, to test IRI equivalence. These methods fall into a range distinguished by the amount of processing required and the degree to which the probability of false negatives is reduced. As noted above, false negatives cannot be eliminated. In practice, their probability can be reduced, but this reduction requires more processing and is not cost-effective for all applications. If this range of comparison practices is considered as a ladder, the following discussion will climb the ladder, starting with practices that are cheap but have a relatively higher chance of producing false negatives, and proceeding to those that have higher computational cost and lower risk of false negatives. 5.3.1. Simple String Comparison If two IRIs, when considered as character strings, are identical, then it is safe to conclude that they are equivalent. This type of equivalence test has very low computational cost and is in wide use in a variety of applications, particularly in the domain of parsing. It is also used when a definitive answer to the question of IRI equivalence is needed that is independent of the scheme used and that can be calculated quickly and without accessing a network. An example of such a case is XML Namespaces ([XMLNamespace]). Testing strings for equivalence requires some basic precautions. This procedure is often referred to as "bit-for-bit" or "byte-for-byte" comparison, which is potentially misleading. Testing strings for equality is normally based on pair comparison of the characters that make up the strings, starting from the first and proceeding until both strings are exhausted and all characters are found to be equal, until a pair of characters compares unequal, or until one of the strings is exhausted before the other. This character comparison requires that each pair of characters be put in comparable encoding form. For example, should one IRI be stored in a byte array in UTF-8 encoding form and the second in a UTF-16 encoding form, bit-for-bit comparisons applied naively will produce errors. It is better to speak of equality on a character-for-character rather than on a byte-for-byte or bit-for-bit basis. In practical terms, character-by-character comparisons should be done codepoint by codepoint after conversion to a common character encoding form. When comparing character by character, the comparison function MUST NOT map IRIs to URIs, because such a mapping would create additional spurious equivalences. It follows that an IRI SHOULD NOT be modified when being transported if there is any chance that this IRI might be used as an identifier. False negatives are caused by the production and use of IRI aliases. Unnecessary aliases can be reduced, regardless of the comparison method, by consistently providing IRI references in an already normalized form (i.e., a form identical to what would be produced after normalization is applied, as described below). Protocols and data formats often limit some IRI comparisons to simple string comparison, based on the theory that people and implementations will, in their own best interest, be consistent in providing IRI references, or at least be consistent enough to negate any efficiency that might be obtained from further normalization. 5.3.2. Syntax-Based Normalization Implementations may use logic based on the definitions provided by this specification to reduce the probability of false negatives. This processing is moderately higher in cost than character-for-character string comparison. For example, an application using this approach could reasonably consider the following two IRIs equivalent: example://a/b/c/%7Bfoo%7D/rosé eXAMPLE://a/./b/../b/%63/%7bfoo%7d/ros%C3%A9 Web user agents, such as browsers, typically apply this type of IRI normalization when determining whether a cached response is available. Syntax-based normalization includes such techniques as case normalization, character normalization, percent-encoding normalization, and removal of dot-segments. 5.3.2.1. Case Normalization For all IRIs, the hexadecimal digits within a percent-encoding triplet (e.g., "%3a" versus "%3A") are case-insensitive and therefore should be normalized to use uppercase letters for the digits A - F. When an IRI uses components of the generic syntax, the component syntax equivalence rules always apply; namely, that the scheme and US-ASCII only host are case insensitive and therefore should be normalized to lowercase. For example, the URI "HTTP://www.EXAMPLE.com/" is equivalent to "http://www.example.com/". Case equivalence for non-ASCII characters in IRI components that are IDNs are discussed in section 5.3.3. The other generic syntax components are assumed to be case sensitive unless specifically defined otherwise by the scheme. Creating schemes that allow case-insensitive syntax components containing non-ASCII characters should be avoided. Case normalization of non-ASCII characters can be culturally dependent and is always a complex operation. The only exception concerns non-ASCII host names for which the character normalization includes a mapping step derived from case folding. 5.3.2.2. Character Normalization The Unicode Standard [UNIV4] defines various equivalences between sequences of characters for various purposes. Unicode Standard Annex #15 [UTR15] defines various Normalization Forms for these equivalences, in particular Normalization Form C (NFC, Canonical Decomposition, followed by Canonical Composition) and Normalization Form KC (NFKC, Compatibility Decomposition, followed by Canonical Composition). Equivalence of IRIs MUST rely on the assumption that IRIs are appropriately pre-character-normalized rather than apply character normalization when comparing two IRIs. The exceptions are conversion from a non-digital form, and conversion from a non-UCS-based character encoding to a UCS-based character encoding. In these cases, NFC or a normalizing transcoder using NFC MUST be used for interoperability. To avoid false negatives and problems with transcoding, IRIs SHOULD be created by using NFC. Using NFKC may avoid even more problems; for example, by choosing half-width Latin letters instead of full-width ones, and full-width instead of half-width Katakana. As an example, "http://www.example.org/résumé.html" (in XML Notation) is in NFC. On the other hand, "http://www.example.org/résumé.html" is not in NFC. The former uses precombined e-acute characters, and the latter uses "e" characters followed by combining acute accents. Both usages are defined as canonically equivalent in [UNIV4]. Note: Because it is unknown how a particular sequence of characters is being treated with respect to character normalization, it would be inappropriate to allow third parties to normalize an IRI arbitrarily. This does not contradict the recommendation that when a resource is created, its IRI should be as character normalized as possible (i.e., NFC or even NFKC). This is similar to the uppercase/lowercase problems. Some parts of a URI are case insensitive (domain name). For others, it is unclear whether they are case sensitive, case insensitive, or something in between (e.g., case sensitive, but with a multiple choice selection if the wrong case is used, instead of a direct negative result). The best recipe is that the creator use a reasonable capitalization and, when transferring the URI, capitalization never be changed. Various IRI schemes may allow the usage of Internationalized Domain Names (IDN) [RFC3490] either in the ireg-name part or elsewhere. Character Normalization also applies to IDNs, as discussed in section 5.3.3. 5.3.2.3. Percent-Encoding Normalization The percent-encoding mechanism (section 2.1 of [RFC3986]) is a frequent source of variance among otherwise identical IRIs. In addition to the case normalization issue noted above, some IRI producers percent-encode octets that do not require percent-encoding, resulting in IRIs that are equivalent to their non encoded counterparts. These IRIs should be normalized by decoding any percent-encoded octet sequence that corresponds to an unreserved character, as described in section 2.3 of [RFC3986]. For actual resolution, differences in percent-encoding (except for the percent-encoding of reserved characters) MUST always result in the same resource. For example, "http://example.org/~user", "http://example.org/%7euser", and "http://example.org/%7Euser", must resolve to the same resource. If this kind of equivalence is to be tested, the percent-encoding of both IRIs to be compared has to be aligned; for example, by converting both IRIs to URIs (see section 3.1), eliminating escape differences in the resulting URIs, and making sure that the case of the hexadecimal characters in the percent-encoding is always the same (preferably uppercase). If the IRI is to be passed to another application or used further in some other way, its original form MUST be preserved. The conversion described here should be performed only for local comparison. 5.3.2.4. Path Segment Normalization The complete path segments "." and ".." are intended only for use within relative references (section 4.1 of [RFC3986]) and are removed as part of the reference resolution process (section 5.2 of [RFC3986]). However, some implementations may incorrectly assume that reference resolution is not necessary when the reference is already an IRI, and thus fail to remove dot-segments when they occur in non-relative paths. IRI normalizers should remove dot-segments by applying the remove_dot_segments algorithm to the path, as described in section 5.2.4 of [RFC3986]. 5.3.3. Scheme-Based Normalization The syntax and semantics of IRIs vary from scheme to scheme, as described by the defining specification for each scheme. Implementations may use scheme-specific rules, at further processing cost, to reduce the probability of false negatives. For example, because the "http" scheme makes use of an authority component, has a default port of "80", and defines an empty path to be equivalent to "/", the following four IRIs are equivalent: http://example.com http://example.com/ http://example.com:/ http://example.com:80/ In general, an IRI that uses the generic syntax for authority with an empty path should be normalized to a path of "/". Likewise, an explicit ":port", for which the port is empty or the default for the scheme, is equivalent to one where the port and its ":" delimiter are elided and thus should be removed by scheme-based normalization. For example, the second IRI above is the normal form for the "http" scheme. Another case where normalization varies by scheme is in the handling of an empty authority component or empty host subcomponent. For many scheme specifications, an empty authority or host is considered an error; for others, it is considered equivalent to "localhost" or the end-user's host. When a scheme defines a default for authority and an IRI reference to that default is desired, the reference should be normalized to an empty authority for the sake of uniformity, brevity, and internationalization. If, however, either the userinfo or port subcomponents are non-empty, then the host should be given explicitly even if it matches the default. Normalization should not remove delimiters when their associated component is empty unless it is licensed to do so by the scheme specification. For example, the IRI "http://example.com/?" cannot be assumed to be equivalent to any of the examples above. Likewise, the presence or absence of delimiters within a userinfo subcomponent is usually significant to its interpretation. The fragment component is not subject to any scheme-based normalization; thus, two IRIs that differ only by the suffix "#" are considered different regardless of the scheme. Some IRI schemes may allow the usage of Internationalized Domain Names (IDN) [RFC3490] either in their ireg-name part or elsewhere. When in use in IRIs, those names SHOULD be validated by using the ToASCII operation defined in [RFC3490], with the flags "UseSTD3ASCIIRules" and "AllowUnassigned". An IRI containing an invalid IDN cannot successfully be resolved. Validated IDN components of IRIs SHOULD be character normalized by using the Nameprep process [RFC3491]; however, for legibility purposes, they SHOULD NOT be converted into ASCII Compatible Encoding (ACE). Scheme-based normalization may also consider IDN components and their conversions to punycode as equivalent. As an example, "http://résumé.example.org" may be considered equivalent to "http://xn--rsum-bpad.example.org". Other scheme-specific normalizations are possible. 5.3.4. Protocol-Based Normalization Substantial effort to reduce the incidence of false negatives is often cost-effective for web spiders. Consequently, they implement even more aggressive techniques in IRI comparison. For example, if they observe that an IRI such as http://example.com/data redirects to an IRI differing only in the trailing slash http://example.com/data/ they will likely regard the two as equivalent in the future. This kind of technique is only appropriate when equivalence is clearly indicated by both the result of accessing the resources and the common conventions of their scheme's dereference algorithm (in this case, use of redirection by HTTP origin servers to avoid problems with relative references).

2 1

Proposed agenda for Nov. 16 call
by Hiro Kishimoto 16 Nov '05

16 Nov '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Nov. 16 Wednesday from 4pm to 6pm (CST). Dial-in numbers for Wednesday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 1116 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (Nov. 14) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051114/en/1 Agenda bashing 2) naming issues resolution process discussion (20 min hard-bound) Discuss how to proceed resolving naming issues For example; - identify requirements and open issues - collect position statements from all stakeholders - prioritize requirements and acceptable solutions to reach rough consensus 3) OGSA-WG January F2F schedule (20 min) Review F2F agenda proposal (attached) Also uploaded to the GridForge https://forge.gridforum.org/projects/ogsa-wg/document/2006Jan-OGSA-F2F-agen… 4) EMS discussion (30 min) (1) review sequence diagrams from composite roadmap 2.4 Job Termination 2.5 Dynamic Job Selection (2) Review Ian's comments on 2.3 Selected Job Execution > I need to see more details on what is being proposed in terms of a > selector interface, but I would be concerned if there was an attempt > to incorporate this as a primitive. As the brief and > far-from-comprehensive list above shows, there are many different > resource selection strategies that may be applied, and these > strategies may be applied in many different ways and in different > places. (3) Deployment and configuration scenarios break down Based on the discussion at the last CDDLM/ACS joint call, I think we need more fine grain scenarios breakdown for chapter 3. EMS Architecture Composition Roadmap (incorporate Nov. 9th CDDLM/ACS joint discussion) https://forge.gridforum.org/projects/ogsa-wg/document/proposed-ems-roadmap/… 5) information model discussion (20 min) > Action: Andrew to review and point out what is needed for the > BES container > - Goal: A preliminary set of attributes that are > needed for the BES container 6) Glossary 1.5 discussion (20 min) At Nov. 14 call, we agreed that from now on a 10-15 minute slot must be reserved on *each call* for a brief glossary review. 7) Wrap up AOB <Basic security profile - secure channel - submission plan> - Prepare a new draft by Wed (Today) - Do the final review next Monday (Nov. 21) - Make the final call after that and submit by Nov'30 (Cannot do earlier given the Thanksgiving holiday) <NEXT CALL> Nov. 21 (Mon) OGSA-AuthZ joint call OGSA Basic Security Profile final review Architecture & Glossary 1.5 Profile Definition Update Nov. 23 (Wed) NO call (Thanksgiving) Nov. 28 (Mon) Architecture & Glossary 1.5 Profile Definition Update Nov. 30 (Wed) EMS architecture, information model & CIM profile Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 0

RE: [ogsa-wg] Re: [ogsa-naming-wg] ... without wsa:Address profil e, AbstractName is meaningless ...
by Maguire_Tom＠emc.com 15 Nov '05

15 Nov '05

So we have had this discussion several times now. I suggest that when the WS-Addressing 1.0 WSDL Binding becomes a recommendation that the wsa:Address will not be treated by the tooling as a URL. Further the fact that current tooling gets it wrong is not surprising given that there is no normative profile for WS-Addressing. While I understand the tooling issues I would be extremely hesitant to base an architectural decision on vagaries of tooling. 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. With that as a base understanding is there any argument, other than URL tooling, that you can articulate against using the wsa:Address IRI field as a unique resource identifier? Tom -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Mark Morgan Sent: Tuesday, November 15, 2005 11:11 AM To: 'Steve Loughran' Cc: ogsa-naming-wg(a)ggf.org; ogsa-wg(a)ggf.org Subject: RE: [ogsa-wg] Re: [ogsa-naming-wg] ... without wsa:Address profile, AbstractName is meaningless ... I'm concerned that by saying that we will start using the Address field for uniqueness and comparison reasons that that is going to place a MUCH heavier burden on the tooling, programers, and users then the abstract name does currently. All of my web services right now have URLs in the Address field because that's what the tooling supports and clearly the URL is not unique for all resource endpoints (I in fact have thousands of resource endpoints residing on my machine right now at exactly one URL). Using IRIs or URIs in the address field of the EPR is great on paper, but I don't know of any tooling that in fact supports that. > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf > Of Steve Loughran > Sent: Monday, November 14, 2005 12:16 PM > Cc: ogsa-naming-wg(a)ggf.org; ogsa-wg(a)ggf.org > Subject: Re: [ogsa-wg] Re: [ogsa-naming-wg] ... without wsa:Address > profile, AbstractName is meaningless ... > > Mark McKeown wrote: > > Hi Frank, > > The Web Architecture > > (http://www.w3.org/TR/webarch/#identification) > > discusses and provides guidance on the issues you describe of IRI > > collision, IRI aliases etc. Does this document not address > the issues > > of the profile work you are suggesting? > > > > When you advocate using the wsa:Address for the > AbstractName are you > > saying that there is no need for adding the AbstractName > element from > > WS-Naming into the EPR or are you saying that the > wsa:Address (or some > > combination of the > > wsa:Address+wsa:ReferenceParameters) should be used in the > > AbstractName element. > > > > eg. > > <wsa:EndpointReference > > xmlns:wsa="http://www.w3.org/2005/03/addressing" > > xmlns:name="http://ggf.org/name"> > > <wsa:Address>http://ggf.org/example/B944388</wsa:Address> > > > > > <name:AbstractName>http://ggf.org/example/B944388</name:AbstractName> > > </wsa:EndpointReference> > > And if so, is everyone expected to (a) have read and understood > section 3.2.3. on the subject of URI equivalence(below), or (b) to > explicitly require case-sensitive-string-matching as the comparison. > > In the case above, are the following abstract names equivalent? > > <name:AbstractName>http://GGF.ORG/example/B944388</name:AbstractName> > <name:AbstractName>http://GGF.ORG:80/example/B944388</name:Abs > tractName> > <name:AbstractName>http://ggf.org:/example/B944388</name:AbstractName> > <name:AbstractName>HTTP://ggf.org/%65xample/B944388</name:Abst > ractName> > > I ask, as for the test document for CDDLM, I need to define > equivalence of things. And as EPR equivalence is so troublesome I am > looking at WSDM ResourceIDs, but even there you have to specify what > equivalence logic you will be using. > > -steve > > --------------------- > RFC2616 on comparisons. Note that java.net does not implement this > logic: > > 3.2.3 URI Comparison > > When comparing two URIs to decide if they match or not, a client > SHOULD use a case-sensitive octet-by-octet comparison of the > entire > URIs, with these exceptions: > > - A port that is empty or not given is equivalent to the > default > port for that URI-reference; > > - Comparisons of host names MUST be case-insensitive; > > - Comparisons of scheme names MUST be case-insensitive; > > - An empty abs_path is equivalent to an abs_path of "/". > > Characters other than those in the "reserved" and "unsafe" sets > (see > RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding. > > For example, the following three URIs are equivalent: > > http://abc.com:80/~smith/home.html > http://ABC.com/%7Esmith/home.html > http://ABC.com:/%7esmith/home.html >

1 0

... without wsa:Address profile, AbstractName is meaningless ...
by Frank Siebenlist 15 Nov '05

15 Nov '05

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. 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. 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 has been reiterated in a number of emails, but i wanted to call it out separately to facilitate the discussion whether the observation holds water and if so, whether such a EPR-minter Address-profile should become part of the ws-naming spec. Again, I would especially welcome comments/reactions/acknowledgments from the ws-naming authors... Regards, Frank. PS. Note that everywhere I wrote "Address" above, it should probably be substituted by "Address+ReferenceParameters", but this simplification doesn't change the observation. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

4 4

Proposed agenda for Nov. 14 call
by Hiro Kishimoto 14 Nov '05

14 Nov '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Nov. 14th Monday from 4pm to 6pm (CST). The dial-in number for Monday; Free: +1-866-639-4741 Toll: +1-574-935-6703 PIN: 8980700 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 1114 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (Nov. 9) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051109/en/1 Agenda bashing 2) Common UML tool review (20 min) Mike sent out his study summary to the list. Thanks Mike! Let's learn what he found. http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/11/msg00053.html > - One of the IBM participants will follow up and confirm the > procedures needed and that everyone can use the RSM tool, if the > group decides to go with it. 3) OGSA workshop at Israel Grid Alliance (20 min) Steve Crumb ask us to send a rep to Tel Aviv before or after GGF16. > In my continued efforts to get an OGSA expert to Israel to discuss > the architecture to a primarily technical audience, Avner and I have > settled on the proposal of having an OGSA half-day workshop > immediately after (or before) the Athens event. This would allow for > someone to be roughly in the same geographic area making a quick, > one-day hop to Tel Aviv much more doable. 4) Basic Security Profile document review (60 min) Takuya will post revised draft before the call. 5) Architecture & Glossary 1.5 discussion (if time permits) 6) Wrap up AOB <NEXT CALL> Nov. 16 (Wed) EMS architecture, information model & CIM profile Nov. 21 (Mon) OGSA-AuthZ joint call Architecture & Glossary 1.5 Profile Definition Update Nov. 23 (Wed) NO call (Thanksgiving) Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

2 1

RE: [ogsa-wg] Teleconference minutes - 9 November 2005
by Maguire_Tom＠emc.com 14 Nov '05

14 Nov '05

So is OGSA-Naming suggesting that the agreed upon algorithm for uniqueness in time and space is RFC4122? There are several well known issues with UUIDs that should be considered. The general algorithm uses the Mac address (in fact the algorithm piggy backs on the uniqueness of the mac address and adds a timestamp component for uniqueness over and above the mac addr). There have been a number of discussions about privacy and the UUID/GUID algorithms w.r.t mac addresses. Additionally, as the authors themselves point out in RFC4122 there are circumstances where duplicates may occur; failure of a node and restart, migration of network card to another machine. There is also no way to ensure that a UUID is 'valid'. Also please be careful; if you ever need to resolve a UUID to a reference it will be next to impossible. So in short, I think there are considerable technical issues with UUIDs. I will point out that the general pattern that UUIDs use is: 1) Base uniqueness by some body handling registration (IEEE does this for mac addresses) 2) Agreed upon algorithms or encoding schemes for spatial uniqueness within the uniqueness provided by point 1 This is not terribly different from URI pattern: 1) Base uniqueness by IANA for domain names 2) Agreed upon encoding scheme for pathing after base The not so subtle difference is that you can resolve a URI.... Tom -----Original Message----- From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Mark McKeown Sent: Monday, November 14, 2005 8:53 AM To: Andreas Savva Cc: 'ogsa-wg' Subject: Re: [ogsa-wg] Teleconference minutes - 9 November 2005 A comment on the minutes... "* Naming Policy discussion Tom sent out the naming policy proposal to the list before the call. Briefly it states that OGSA fellow WG specifications must return EPRs. The EPRs may be decorated with more information but there should be no normative statement in the specifications that that information must be present. One technical issue is the level of coordination required for mandating WS-Names. The main point being the difficulty of quaranteeing uniqueness-in-space-and-time. For the uniqueness statement to be true an algorithm to create a unique string must be specified and everyone must agree to use it, which introduces a new set of problems." Is this technical issue not addressed by IETF RFC 4122, "A Universally Unique IDentifier (UUID) URN Namespace"? http://www.ietf.org/rfc/rfc4122.txt cheers Mark ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Mc Keown RSS Mark.McKeown(a)man.ac.uk Manchester Computing +44 161 275 0601 University of Manchester ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On Mon, 14 Nov 2005, Andreas Savva wrote: > Minutes attached. Main topics: > * EMS and CDDLM, ACS joint discussion > * Naming Policy discussion > > https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051109 > /en/1 > -- > Andreas Savva > Fujitsu Laboratories Ltd >

2 1

Teleconference minutes - 9 November 2005
by Andreas Savva 14 Nov '05

14 Nov '05

Minutes attached. Main topics: * EMS and CDDLM, ACS joint discussion * Naming Policy discussion https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051109/en/1 -- Andreas Savva Fujitsu Laboratories Ltd Teleconfence Minutes - 9 November 2005 ====================================== * Participants Michael Behrens (R2AD, LLC) Ian Foster (ANL) Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Allen Luniewski (IBM) Tom Maguire (EMC) Dejan Milojicic (HP) Mark Morgan (UVa) Takuya Mori (NEC) Steven Newhouse (OMII) Andreas Savva (Fujitsu) Stuart Schaefer (Softricity) Frank Siebenlist (ANL) Ellen Stokes (IBM) Jay Unger (IBM) Jem Treadwell (HP) Apologies: Fred Maciel, Peter Ziu Minutes: Andreas Savva * Minutes approval ** November 7 minutes approved with minor corrections - Clarify that it is the sophisticated estimation of deployment time is not a high priority. (Per Hiro's email to OGSA-WG ml) (Done) ** November 2 minutes: - Add Manuel Pereira to participants (Done) * EMS and CDDLM, ACS joint discussion - A number of ongoing discussions on the list. There seems to be convergence on many issues. - Remaining discussion points: 1. Where to draw the line in the CDL tree (aka deployment vs provisioning) - CDDLM team to follow up with Jay 2. EMS requirements for deployment - CDDLM team to follow up with Andrew 3. What kind of information CSG (RSS-WG) expects to get from an ACS repository. Or, more generally what kind of information CSG expects to be able to get and from where. - Hiro has started a discussion with the RSS-WG - CDDLM and ACS services should be added to the EMS architectural diagrams - Deployment requests to CDDLM deployment service - Static information about applications to the (ACS) repository - Dynamic information to information services - CDDLM services could provide information about which applications are installed where - (And optionally, if needed, an estimate of deployment cost--- keeping in mind previous discussions that such estimates are unlikely to be accurate.) - Deployment versus provisioning requirements (Or, where to 'cut' the CDL tree. Above the 'cut' point is deployment---assumed to be a relatively 'light' operation---and below is provisioning---assumed to be more heavy-weight.) - Deciding the cut point is orthogonal to CDDLM---it is policy or best practices and is therefore a system choice - Information (metadata) to help in making the choice could be added to the CDL as mark up - CDDLM implementations have walked the tree fairly far down (to the hardware) for deployment - CDL may be sufficient to express both deployment and provisioning. But it is an open issue if these two activities can, or should be unified in this way in OGSA. In particular CDL may not be going to the full extent of supporting costing, etc., that maybe needed to address all requirements - Resources beneath the cut point can be considered as pre-provisioned: they either exist or they don't. They are not going to be deployed themselves; but they can be used to deploy on. - Which resource to choose for deployment? It is the choice of the EMS architecture (EPS, CSG) and not of CDDLM. - Discussion on how CDL may be viewed as a hierarchy of scripts; and that one could have a history of costs associated with each node. In other words the tree could be decorated with other information (cost, etc, as metadata) - JSDL and CDL relation and can one cover the requirements for the other - A JSDL submission may be associated with a deployment description or request, and the deployment portion could be described in CDL. [I.e., CDL could be a more specific application sub-type in a JSDL document.] - JSDL is not intended to describe the configuration of the software that will be used by the job. The aim is to describe things at a higher level. There may be similarities between the languages (perhaps around resource description) but it does not mean that one language can, or should, replace the other because they serve different purposes. - Jay wants to pursue the issue further among a smaller group of people. Actions: - Hiro to arrange the next joint call - Tentatively scheduled for Dec'21 due to various conflicts. - Dejan to arrange for a subteam call to discuss in more detail the provisioning/deployment issues, JSDL, CDL, etc. - Volunteers (mainly in Boston area or same timezone): Jay, Andrew, Stuart, Michael. * Naming Policy discussion Tom sent out the naming policy proposal to the list before the call. Briefly it states that OGSA fellow WG specifications must return EPRs. The EPRs may be decorated with more information but there should be no normative statement in the specifications that that information must be present. One technical issue is the level of coordination required for mandating WS-Names. The main point being the difficulty of quaranteeing uniqueness-in-space-and-time. For the uniqueness statement to be true an algorithm to create a unique string must be specified and everyone must agree to use it, which introduces a new set of problems. It was re-stated that the motivation for WS-Names is so that clients do not have to re-invent this kind of functionality. And that (for certain applications) this is really useful functionality. Andrew also read out portions of an email from Marvin Theimer on the need for WS-Names. (Andrew may send out the email to the list with Marvin's permission.) It was pointed out that there are two issues that should be discussed separately: - Reference resiliency; and - Equivalence checking And that Marvin's email calls out the need for resiliency rather than equivalence. In summary the technical issues are: 1. How to make sure that the identifiers (AbstractName) are unique 2. Some people might choose to provide resiliency using different mechanisms; and mandating this particular mechanism (unique identifier) forces implementations to create identifiers that the client software may not require or use. It was clarified that if a specification defines that EPRs are returned it does not stop a particular service implementation from decorating its EPRs with identifiers and therefore returning WS-Names. And that a mechanism to introspect services and determine whether they are in fact returning WS-Names could be provided. And that clients that absolutely require WS-Names could discover appropriate services that way. - For example, some (OGSA) profile might define a claim URI that means that compliant services return EPRs that are in fact WS-Names. Tom also explained that current tooling does not support extended types of EPRs. So defining an extension of EPRs such as WS-Names will *not work* with available tooling. This means that the WSDL defined by a specification such as BES would will still have to be defined as returning an EPR; and it is only some text in the specification that may make extra statements anyway. [So one cannot programmatically discover this feature.] Action: The next step is up to the BES-WG co-chairs: - Discuss this issue on a BES call and decide how to proceed. Options include the BES specification being redefined to return a URI and then also defining an optional porttype to 'resolve' that URI and so on.... Frank also raised the separate issue of whether the current formulation of WS-Naming is adequate. - There is a need to bind policy using unique identifiers. The current formulation of WS-Naming does not provide sufficient support because the unique identifier does not flow on the wire. - For this identifier to be useful for this purpose it must be part of the header of messages on the wire - Currently the AbstractName is defined as metadata so it does not get on the wire - Frank's proposal is to use the wsa:address IRI as the unique identifier - He has proposed this in the past but did not get an adequate response. He will raise it again on the list. Discussion to continue on the list. * Postponed for the future calls ** Common UML tool discussion - Michael to send out his evaluation in advance ** OGSA volunteer to give presentation in Israel ** Information model discussion - Postponed for next week. - It is pending on Andrew to provide the information that Ellen has asked for. * Next week - Agreed that despite SC'05 there should be sufficient people participating so the calls can go ahead as planned. - Monday call - Basic security profile (Takuya to send out final draft) - UML tool review - OGSA representative to Israel - The OGSA-AuthZ discussion should be re-scheduled for November 21 since it is not clear if members of AuthZ can participate (due to SC'05).

3 2