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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ekmi message

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


Subject: Re: [ekmi] [Fwd: [ekmi-comment] Request for block of SKSML ErrorCodes for Vendor Use]


The request from a vendor is optional, Anil, but if a vendor wants
to claim conformance to the SKSML spec, they have to implement the
Standard Codes & Messages.  That's the way we've written the spec's
Conformance section.

While vendors might think it burdensome, it isn't really a burden.
The vendor *has* to send some message to the client/system if
something goes wrong; rather than have them come up with their own
message, we're telling them to use a standard one where it exists.
The biggest beneficiaries will be the customers implementing the
SKMS: consistency reduces operations costs for them.

Arshad

Anil Saldhana wrote:
> I know the error code request is optional but somehow the TC will look 
> like managing error codes just the way a central authority takes care of 
> IP address assignment. ;)
> 
> Anil Saldhana wrote:
>> I am not sure whether vendors choosing a block of codes will improve 
>> interoperability.  I also do not know when this appendix D, Section 4 
>> was discussed in the TC. I have serious objection to vendors making 
>> statements that they will implement the specification within 6-12 
>> months and also have objections to the TC doing additional work in 
>> maintenance of vendor requests to error codes.
>>
>> * I am not aware of any other specification taking this route - where 
>> vendors have to request blocks of error codes and have to make 
>> assertions that they will implement in 6-12 months.
>>
>> Please appraise me of how blocks of error codes assigned to vendors 
>> will improve interoperability.
>>
>> Arshad Noor wrote:
>>> Not sure how many of you are on the ekmi-comments@lists.oasis-open.org,
>>> but I thought I'd forward this to the TC list so everyone is aware of
>>> our request.
>>>
>>> Since I'm setting myself up to be the guinea-pig for this process, I
>>> will work with Anil on creating a page on the EKMI Wiki to track this
>>> request.  I'll also setup a ballot for a vote on this request.
>>>
>>> Thanks.
>>>
>>> Arshad
>>>
>>> -------- Original Message --------
>>> Subject: [ekmi-comment] Request for block of SKSML Error Codes for 
>>> Vendor Use
>>> Date: Tue, 13 Jan 2009 15:33:34 -0800
>>> From: Arshad Noor <arshad.noor@strongauth.com>
>>> Organization: StrongAuth, Inc.
>>> To: ekmi-comment@lists.oasis-open.org
>>>
>>> In accordance with Appendix D of the DRAFT SKSML 1.0 Specification
>>> PR02, we would like to request a block of SKSML codes for use by
>>> StrongAuth, Inc.
>>>
>>> We assert the following:
>>>
>>> 1) We will implement the SKSML 1.0 specification within 6-12 months
>>>    of the date of this request;
>>>
>>> 2) We will implement ALL the Standard Codes & Messages as described
>>>    in the SKSML Specification;
>>>
>>> 3) We will not duplicate any Standard Code or message within our
>>>    assigned private vendor block of numbers;
>>>
>>> 4) If the TC later chooses to standardize a specific message within
>>>    the Standard Codes, which may overlap with our assigned private-
>>>    block message, we will use the Standard Code in the implementations
>>>    created subsequent to the standardization of the code/message;
>>>
>>> 5) We will notify the EKMI Technical Committee of the release date of
>>>    our product, highlighting the relevant section of our documentation
>>>    using the Standard Codes and Messages, upon the release of the
>>>    product.
>>>
>>> Thank you
>>>
>>> Arshad Noor - (Authorized representative)
>>> CTO
>>> StrongAuth, Inc.
>>> (408) 331-2000
>>>
>>> -- 
>>> This publicly archived list offers a means to provide input to the
>>> OASIS Enterprise Key Management Infrastructure (EKMI) TC.
>>>
>>> In order to verify user consent to the Feedback License terms and
>>> to minimize spam in the list archive, subscription is required
>>> before posting.
> 


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