OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

orms message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [orms] Minutes of the 6/16/2010 meeting.


Hi Mani

PLEASE READ:This e-mail is confidential and intended for the named recipient only.
If you are not an intended recipient, please notify the sender and delete this e-mail.

My comments are inline:


(6/17/10 12:20 PM), Mani, Mahalingam (Mani) wrote:
> Attendees: Nat, Tatsuki, Mani
>
> Quorum: Yes.
>
> Minute-taker: Mani
>
> Approved: the minutes of the last (quorum’ed) meeting
>
> 1. Tatsuki Explained the document updates made by Tatsuki.
>
> 2. Nat questioned the scope/extent of extensibility
>
> a. Tatsuki: new XML elements can be added to the doc. Namespace is
> extensible.
>

The current draft doesn't specify the extension mechanism in a XML way.
Instead, it provides the <Context> element as "reputation namespace"
for data providers (we need a proper term for this one too) to define
the semantic of data and attributes in <Score> and <Data>.

Adding the XML namespace and extensibility is still TBD.


> 3. Nat asked that reputer element be added to the reputation definition
> in the XML reputation doc.
>
> a. It was also agreed that reputer’s identity and reputation information
> should be accessible from there.
>
> b. Mani: The reputation element is signed by reputer. Nat agrees.
>
> c. Nat: the reputation-bundle itself is signed by bundling reputer.
>

Digital signing is one way to say who is a reputor.
Providing a vaule in the <Reputor> element is another.
The value type in the <Reputor> is TBD. It should be any string IMHO.
Amazon doesn't use URIs to identify their users. It's a mail address
or handle name their users define.

In a casual use cases, the value should allow some flexibility.
What should be in the value is up to use cases. The spec can not define.
  
> [Mani – post-meeting query]: do we need to specify the (signing)
> identity certificate’s profile? And the signature’s encapsulation
> requirements?
>

I wasn't expecting profiling works in this TC.
If we consider the current resource and time we can spend on this,
extending our work to "profiles" is a bit cumbersome.

> 4. Reference model: Mani raised questions about any updates needed to
> reference model in light of the draft evolution?
>
> a. Mani to review the need for any. Tatsuki mentions that all aspects
> are still consistent with reference model in the prior reference document.
>
> b. Mani: A simplified OASIS-ised depiction of the generalized reference
> model focused on the charter and goals of the TC would still be relevant.
>

I agree on simpliying it and make it more relevant to the draft.
Also the terminology section and the reference model should be
well coordinated.

Best,

Tatsuki

> Regards,
>
> -mani
>
> =============
>
> Mahalingam Mani
>
> 408.321.4840 (w)
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]