RE: RIM 0.55 distribution

[Krishna Sankar <ksankar@cisco.com>]

Hi all,

	As with the Soda wars, I do not think the regrep can take up another
responsibility - marriages are a speciality of the Nevada state and if ebXML
wants to start a mXML initative (an infrastructure for long lasting and
spontaneous human relationships ;-)), we should start another group
(possibly headed by Pastor Joe Baran ;-) and assisted by hi-priest Farrukh
as the co=chair)

cheers

> -----Original Message-----
> From: Joseph Baran [mailto:joebaran@extol.com]
> Sent: Friday, January 19, 2001 4:19 PM
> To: 'Farrukh Najmi'; Klaus-Dieter Naujok
> Cc: ebxml-regrep@lists.ebxml.org; 'ebXML Coordination'; 'Nieman, Scott'
> Subject: RE: RIM 0.55 distribution
>
>
>
> Farrukh and Klaus:
>
> Klaus wrote:
> >
> > In closing, the main reason for having the PT submit the request
> > to QRT via the StC was to make sure that all PT lead and the
> > Executive were aware of the fact that a specification was entering
> > the review process.
> >
>
> I don't know if this will answer ALL present difficulties, but...
> If it can be posted VIA the StC list, so that all PT leads and
> execs can see it happen, will that do?
>
> signed,
>
> Joe <trying to be a matchmaker> Baran
>
>
> P.S. - I feel like someone should say:
> "If anyone preset has any reason that this couple should not be
> married, let them speak now or forever hold their peace."
>
>
>
>
> -----Original Message-----
> From:	Farrukh Najmi [SMTP:Farrukh.Najmi@east.sun.com]
> Sent:	Friday, January 19, 2001 7:15 PM
> To:	Klaus-Dieter Naujok
> Cc:	ebxml-regrep@lists.ebxml.org; ebxml-stc@lists.ebxml.org;
> 'ebXML Coordination'
> Subject:	Re: RIM 0.55 distribution
>
> Klaus,
>
> I am told by Nagwa or QR team that the QR team has agreed to take
> new versions
> of specs by tonight to facilitate the ability for RR to submit
> specs that have
> already addressed the known issue by QRT.
>
> IMHO when the bride and the groom agree to get married then the
> priest should
> just bless the ceremony (old middle eastern saying).
>
> I have just gotten done with a 4 hour session with Nagwa on the Registry
> Services document and was told by her to go ahead and submit the changes.
> Having causes enough problems and confusion for the day, I will
> refrain from
> submitting the new RS document unless you (Klaus the priest) give
> the blessing.
>
> IMHO, we could optimize the process tremendously. If you are open to
> suggestions I will be gald to oblige.
>
> Finally, My thanks to the QR team and specially Nagwa for their
> flexibility,
> hard work and the *WILL* to make these specs good enough for
> consideration by
> QR.
>
> --
> Regards,
> Farrukh
>
>
> Klaus-Dieter Naujok wrote:
>
> > On Fri, 19 Jan 2001 12:27:52 -0600, Nieman, Scott wrote:
> >
> > >Finally, for the future, I am authorizing Farrukh to make
> revisions to the
> > >document that are ONLY editorial in nature and submit
> revisions to QRT on
> > >behalf of the team .  "Editorial in nature" is an assumption
> that changes
> > >only provide clarification to QRT concerns.  Any substantive
> changes will
> > >require VOTE by the registry team.  I am assuming that the StC will not
> > >object this the process (please let me know asap if this is an issue).
> >
> > Scott,
> >
> > I understand what you are trying to achieve, however, we have a
> > very lean (simple) process in place that we must follow. I am not
> > aware that there is currently a so to say "interactive" process
> > between QRT and the project team that has submitted a
> > specification to revise on the fly the specification under review.
> > Therefore I don't understand your suggestion for Farrukh to be
> > allowed to submit editorial changes to QRT. I should point out
> > that QRT has approved the TA specification but at the same time
> > had many comments to be addressed as part of the next review.
> > However, the QRT comments against the RIM were more than of
> > editorial nature that could be to be taken care of in the next
> > editing session and therefore they rejected the request to go out
> > for public review.
> >
> > The process is very simple, a PT approves by vote (min 67%) its
> > draft to go for the first public review. It is submitted to QRT
> > for quality review. If QRT recommends that the specification can
> > go out for review, it is made public including any comments from
> > QRT. At the end of the review cycle the PT reviews the public and
> > QRT comments in order to create its next revision. After approval
> > by the PT it goes out for the second cycle using the same process
> > with QRT. At the end of the second review the PT takes again the
> > public comments and QRT comments to prepare the final
> > specification. This version will be made available to the ebXML
> > community 2 weeks before a ebXML meeting in order to approve it
> > during the closing plenary.
> >
> > Should QRT reject the specification, and the Executive does not
> > overrule the QRT, than the PT will have to address the issues by
> > either revising the document or countering the QRT comments. If
> > the PT revises the document PT approval is required to present it
> > back to QRT. Should the PT disagree with QRT it must present it
> > counter arguments to QRT. In the case that QRT disagrees, the
> > Executive will review the issue(s) and make a recommendation to
> > the StC which will take a decision at the earliest time via a
> > conference call. Should the QRT agree with the counter arguments
> > the document as submitted will go out for review.
> >
> > In the case that QRT rejects the specification and the executive
> > disagrees with the rejection, there are two possible actions. If
> > the Executive feels that the reasons are not of technical
> > substance it can take the decision to go out for public review. If
> > the Executive feels that the technical issues raised are not a
> > show stopper or are not valid it will asked the StC to take the
> > decision to allow the specification to go out for review or not.
> >
> > In closing, the main reason for having the PT submit the request
> > to QRT via the StC was to make sure that all PT lead and the
> > Executive were aware of the fact that a specification was entering
> > the review process.
> >
> > Scott, I hope I clarified the process and reasons for it. I have
> > no intentions to put road blocks up, the opposite is true, I want
> > to make sure that we follow our simple process so that no one can
> > claim we short circuiting it, which would mean in the end more
> > work by back tracking.
> >
> > Have a great weekend, looking forward to reading you
> > specifications as they go out for review.
> >
> > Regards,
> >
> > Klaus
> >
> > --
> > Klaus-Dieter Naujok                          ebXML & TMWG Chair
> > Netfish Technologies, Santa Clara, CA, Chief Technology Officer
>
>
>  << File: najmi.vcf >>
>
>