Subject: Re: SV: SV: SKiCal & Roles

From: [email-masked]
Date: Tue, 21 Nov 2000 17:34:43 +0000

Greg,  there could potentially be multiple drafts that occur that work in 
conjunction with RFC 2445.  An example that comes to mind is RFC822.  Many 
drafts reference it, but do not change what RFC 822 stated.  Nor was RFC 
822 changed to work with the other drafts.

I don't think it is appropriate in this case to change RFC 2445.  What you 
requested is not a change to something "broken".  If a draft does have a 
flaw or is wrong, then it is appropriate to change it.  I don't see where 
your requested change is a "fix."

Therefore, you need to follow a path of referencing  RFC2445 and state 
where your draft "enhances" or "extends" or some sort of language, the RFC 
2445 draft.  It would be impossible to keep up a RFC if we had to go and 
change it every time a new draft comes into play that uses or references 
it..  Hope this helps with your thinking a bit.

"Greg FitzPatrick" <[email-masked]>
Sent by: [email-masked]
11/21/00 07:37 AM

        To:     "John Stracke" <[email-masked]>, "Ietf" <[email-masked]>
        cc: 
        Subject:        SV: SV: SKiCal & Roles

john wrote :
And, if it can't be reused, then it probably shouldn't be called
a role at all; too confusing.

Any suggestions:-?

"Function" comes to mind.

Greg

---

From: Pär Lannerö <[email-masked]>
Date: Wed, 22 Nov 2000 10:58:15 +0100

[email-masked] wrote:
> Greg,  there could potentially be multiple drafts that occur that work
> in conjunction with RFC 2445.  An example that comes to mind is
> RFC822.  Many drafts reference it, but do not change what RFC 822
> stated.  Nor was RFC 822 changed to work with the other drafts.
> 
> I don't think it is appropriate in this case to change RFC 2445. 

I believe that Greg did not propose a change to 2445, but asked for
advice on what parameter to use in the SKICal specification, which is a
draft "that work in conjunction with RFC 2445". Just as you suggest
above. Greg wrote in his original posting "We were in agreement that the
only reason for adding three additional property parameters was to avoid
conflict with 2445."

The question is: Should the SKICal specification reuse ROLE, as defined
in RFC2445, just as it reuses most of 2445, or should it define a new
parameter DIPROLE which is a bit wider in value domain than ROLE?

The question arises since the purpose of ROLE is "To specify the
participation role for the calendar user specified by the property"
(with typical values CHAIR, REQ-PARTICIPANT) while the need in a SKICal
context is "To specify the participation role for a _person_ specified
by the property" (with typical values "CONDUCTOR", "SOLOIST",
"PRODUCER"...).

regards,
Pär

> What
> you requested is not a change to something "broken".  If a draft does
> have a flaw or is wrong, then it is appropriate to change it.  I don't
> see where your requested change is a "fix."
> 
> where your draft "enhances" or "extends" or some sort of language, the
> RFC 2445 draft.  It would be impossible to keep up a RFC if we had to
> go and change it every time a new draft comes into play that uses or
> references it..  Hope this helps with your thinking a bit.

-- 
Pär Lannerö, Infostructure developer, Metamatrix AB, Stockholm
Mail: <[email-masked]>  Cellphone: +46 739 44 20 43
Work web: www.metamatrix.se   Personal web: www.lannero.com/p/