Minutes, OGSA Telecon, 6 June 2005

Minutes, OGSA Telecon, 6 June 2005

Attendees

------

Hiro Kishimoto

Mark Morgan (Minutes)

Jem Treadwell

Tom Maguire

Takuya Mori

Dave Berry

Andreas Savva

Mike Behrens

Fred Maciel

Ravi Subramanium

* Agenda

* Profile Discussion

* Roadmap Discussion

* Telecon Minutes from last week, not available yet. Postpone approval for next time.

* Agenda

- Basic Profile

- Roadmap

- Other Business?

-- Discussion of who has pen to make changes on consortium standardization in specification. Is

it Jem?

-- Jem submitted.

-- Tom now has pen.

-- Tom to fix two things from Hiro on profile description

-- Can we do roadmap before basic profile?

-- that's fine

* Roadmap Discussion

- Going through document.

- People had been saying that profiles were about defining interoperability -- they didn't define

what

what was and what wasn't OGSA. Wording changed to make this clearer and make it consistent.

- Trouble with view that we have specifications and profiles. Seems strange that profiles only

define

interoperability and that you need specifications above and beyond profiles. Clearly there will

be specs.

developed, but in terms of describing a set of specs. that are used for a particularly

discipline withing

OGSA, it seems like profiles are the way you would have to describe that. Understand intent,

but does

this wording capture it?

- This comes from idea that WS-Naming was a profile and we said, no it's a specification.

- You define protocols withing OGSA specifications, but how those are composed with other

specifications for

the purposes of interoperability is for a profile.

- The thing you do compliance or conformance against is a profile, not a specification

- Not sure that that was clear in previous discussions of profiles.

- That needs to be made more clear

- Two or three people need to read the text very carefully offline and see if it says what we want

- Try to organize that.

- On 2.3, trouble with conformance and compliance claims.

-- This is an attempt to capture a conversation that happened earlier

-- This is ok -- really just a way of categorizing implementations.

-- Can you make a note here to add a recommendation that conformance claims mechanism described

in

the profile should be used to communicate conformance.

-- Just because a set of tests exist, would you be able to claim compliance. Providing a way of

verifying

compliance does not imply certification of that necessarily.

-- There are no test suites for conformance.

-- Compliance usually has to do with a legal branding.

-- Whoever owns the brand, generally it behooves them that they make sure that they are

protecting their

asset.

-- In other words, does compliance imply a licensing aspect.

-- At this moment, their are no compliance tests, but we have to be ready for it in the future.

- 2.4 on Branding

-- This follows compliance section -- would have expected some follow on to the compliance thing.

-- Branding is intimately linked with compliance to some

-- But, here we are using more to talk about working groups and documents and things

-- Following the compliance section, we would expect different content then what is here now

-- This was based on content that was there before. This is a condensing of that

- Should we add the concept of software? Seems like part of branding.

- Even the GFSG does not talk about software branding issues.

- You could just combine 2.3 and 2.4 and call it OGSA Branding.

- 3.1 The purpose of normative profiles is not in the architecture document

-- Point was that in the arch. document we would mention this. Maybe we shouldn't

-- Should we just describe the use of these?

-- Andreas would prefer reducing the text of this as much as possible -- we haven't decided what

1.5 will do.

-- We don't need to get into too much detail here when we have described what the 1.5 document

will

contain.

-- For the glossary, we will have to define things like profiles.

- 3.6.1

-- Probably can't give dates yet -- probably doesn't have any.

-- We have to have table here and get WSM to give us dates

- A vocabulary would define semantics. Vocabulary management would deal with how different groups

would

deal with different semantics. How to avoid clashes.

-- Like ontoloyontology? Sort of, but not that far

-- Get Abdelsum to give more explanation?

-- Yes, Hiro to send email

- 4.1.2 - Coloring issue that needs to be resolved.

-- original intent of shading was to group things that went together. Probably was overkill.

-- The only reason not to do it though is if it gets lost as people copy it. As long as we get

it right, it's

OK.

-- Table 4.3 has more shade -- we probably have some inconsistencies.

- Expected use of ACS section, Hiro change a lot. Mike, please review this section. Mike says it

look OK

- We don't have adoption level of profiles do we?

- Think we do. You can try and implement your profile and there are interoperability tests.

- We have conformance claims that people make to profiles.

- A profile has the adoption level of the least supported component.

- Not sure what it means.

- Is a profile all or nothing

-- No, it isn't necessarily completely required.

-- But what about all or nothing of the mandatory pieces

-- yeah, usually.

-- But, even for the optional pieces, it seems silly to say you can implement the profile even if

pieces which

can't be implemented are optional

- The WSRF Basic Profile does not list the WS-I basic profile -- it's an extension of this

- Seems like you can't put a profile at the same level as a spec.

- Profile is sort of a basket of implementable specs.

- The character and nature of a profile is somewhat different from a specification. Would prefer

to see something that

says that BES is an extension of the WSRF Basic Profile 1.0

- You could create another table that talks about extended profiles.

- What about moving the profile up, but then put the referent specifications in the table.

- For now, can we put a line that says that anywhere there is a reference to a profile we pull it

out of the table and

say something about it above.

- Even if we can't say something about adoption level, status level would still be good.

- How about keep it in table, but grey out the adoption level side.

- Does status of the profile mean status of profile itself, or specs in the profile?

-- Profile itself.

- Ideally it would be good to have a master table in the appendix -- Jem working on this.

- Can we make it clearer that the status of a profile is the status of the profile itself?

- Evolving means before the GFD recommendation proposal. If it becomes a GGF publication, then

status is

institutional.

- Status should be at the time of GGF editor submission.

- At that time, the WSRF Basic Profile is also at the same stage

- It has not gone through the public comment review so it is not yet GGF Public Document.

- We believe it is stable enough to call it evolving.

- Time check -- we're over time. Do we postpone Tom's until Wednesday call.

- Continue Roadmap review

- Need to have discussion about whether or not a spec. can reference another spec. as per Ravi's

confusion about

whether or not BES is a profile or a spec.

- Should a table include stuff that is in the WSDL if it isn't in the document?

-- Yeah -- the normative document is in error for not listing them.

- Do we really want to put the version numbers in the table as opposed to hyperlinks?

-- Hyperlinks don't work for GGF document.

-- Cross Reference would

-- Fact is that some specifications refer to other versions of the same specification.

-- Those are two different references then

-- You are going to end up re-creating the URL for where the documents are located as text. It's

not going to

be sufficient to just put a number there.

-- Want to put at least the version number in the table.

-- There needs to be a cross reference for that that gets you to the document.

-- If we have a table then we can link to that.

-- We'll still have to have proper citations and references.

-- If we need more time, we'll spend more calls to finalize this document. It's more important

to complete

old issues before submission. Fortunately one or two more weeks before GGF

- WS-Security roadmap was published a couple of years ago, but not activity since then.

-- That roadmap document stated many components that would be used for our security stuff.

-- WS-Policy and WS-Trust, etc. described in that document

-- Not sure what the plan is

-- Worried that the security roadmap document listed a bunch of specs. Some of them are

publicallypublicly avail.

One is in standards organization

-- You are free to reference something not in a standards body, but that means that your document

is

informational only.

- Example implementations

-- Hiro to send text to Ian to get comments.

- We have to look at the trackers

-- only ones unresolved are the branding ones and the compliance tests one

- Jem to update it over the next few days and upload

- We will need to have another call

- Object to get it into good shape for a swift discussion next Monday.