Subject: RE: IPTEL spec and iCalendar

From: [email-masked]
Date: Fri, 26 Jan 2001 15:38:58 +0000

Shannon, you are correct. I can't even imagine how all the working groups 
keep track of what is called in a spec.  When you think about the POP, 
IMAP and LDAP items that are used extensively, how do those groups keep up 
with other drafts and specifications that use their protocols?  This is 
much bigger than it appears on the surface.  I think John's idea is a good 
one and something similar for working on other groups would be particulary 
helpful.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

"Shannon J. Clark" <[email-masked]>
Sent by: [email-masked]
01/25/01 11:44 PM

        To:     <[email-masked]>
        cc: 
        Subject:        RE: IPTEL spec and iCalendar

It seems to me that monitoring the announcements and passing along 
important
ones would be a useful tool, might want to be shared with other working
groups as well - if this problem is occurring with the iCalendar standard, 
I
have to assume that other standards have and are having the same problem,
different groups using or modifying a standard without reference back to 
the
standards groups.

Just a thought on my part.

Shannon

Shannon J. Clark
CEO - JigZaw, Inc
1.800.4.JIGZAW (454.4929)
[email-masked]
www.jigzaw.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of John Stracke
Sent: Thursday, January 25, 2001 4:45 PM
To: [email-masked]
Subject: Re: IPTEL spec and iCalendar
Importance: High

John Stracke wrote:

> Patrik Fältström wrote:
>
> > At 10.48 -0500 01-01-25, John Stracke wrote:
> > >Was there a mechanism to tell us that it used iCalendar?
> >
> > Grep is your friend.
>
> Point taken.  :-) I'll dust off the procmail manpage.

Tonight or tomorrow, I'm going to set up a tool to monitor the I-D
announcements and look for interesting ones.  I'm thinking of having
the calsch-related ones it finds go to the calsch list.  Anybody
object?

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |In the country of the blind, the one-eyed man is|
[email-masked]|in therapy.                                     |
\=================================================================/

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 26 Jan 2001 22:36:20 +0100

At 15.38 +0000 01-01-26, [email-masked] wrote:
>When you think about the POP, IMAP and LDAP items that are used 
>extensively, how do those groups keep up with other drafts and 
>specifications that use their protocols?

Rule number one is that the group of people creating the _new_ thing 
should contact the group which have standardized whatever they are 
inheriting. This we must trust people doing.

But, we also have a review process, and the review process is 
supposed to check that rule number one really has been fulfilled.

The formal steps we have is the IETF Last Call, and the review by 
members of the IESG.

I don't want this to be more formal than this -- because all 
formalities take time.

On the IESG, myself and Ned as Apps AD's do catch most such things (I 
can not remember a single one I have missed), but unfortunately when 
we find one we need responses fast -- as the IESG can not have one 
paper on our table for so long time. We get about 10 new I-D's on our 
plate a week.

So, it is _my_ job to do this stuff, but, I apreciate all help I can 
get as you are the ones which know the details.

    Patrik

-- 
Patrik Fältström <[email-masked]>       Internet Engineering Task Force
Area Director, Applications Area                   http://www.ietf.org
Phone: (Stockholm) +46-8-4494212            (San Jose) +1-408-525-0940
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Mon, 29 Jan 2001 11:46:30 +0100

I can relate to this from a SkiCal angle.   Though SkiCal  is an extension
of iCal and CPL a “call processing language” using XML syntax, two quite
divergent efforts,  the authors of both drafts have tried to reuse previous
work and not reinvent when possible.

CPL uses XML syntax.  ( Though I wonder if they took a good look at RDF,
which might have suited their purposes even better.)

  In §2.4 XML Structure  they equate “nodes” and “outputs” with “XML tags”
(I believe they should have used the term “Elements”) and “parameters” with
“XML tag Attributes”.  (again – skip the tag!) so I believe the map is…

(CPL  Nodes & Outputs) eqv. (Mime-directory Component Properties) eqv. (XML
Elements)
(CPL Parameters) eqv. (Mime-directory Property Properties) eqv. (XML
Attributes)

I am not sure where this puts Calendar Components – but they are not part of
the deal here so that is irrelevant.  For reference here is the Map that
Frank Dawson did in his iCal DTD from 19990220

(Mime Directory Calendar Components) eqv. (XML Elements)
(Mime Directory Calendar Properties) eqv. (XML Attributes)
(Mime Directory Component Properties) eqv. (XML Elements)
(Mime Directory Property Parameters) eqv. (XML Attributes)
(Mime Directory Value Types) eqv. (XML Value Types)

In § 5.3 Time switches, the CPL authors reference first tzid and tzurl, and
then dtstart, dtend/duration using the term “parameters”.   Actually in 2445
TZID and TZURL are Properties but tzid is also confusingly a general
property parameter.

Other names referred to as parameters are:

dtstart
dtend
duration

all of which are Component Properties in 2445

freq
interval
which are value type components  of the Recurrence Rules value type: RECUR
in 2445 and processed first and independently from…

until
byday
bymonthday
byyearday
byweekno
bymonth
wkst
	which are also value type components of the Recurrence Rules and not
properties and not parameters either..

In other words there is a bit of a term muddle here which should be worked
out.  If Properties, property parameters and property values are all going
to turn into  parameters - be careful about it.  At least be careful if some
sort of interoperability with iCal applications is intended.

I also would caution against using attributes to qualify their sibling
attributes rather than their parent  element as  the authors have done.
This is not good ER.  One solution would be to nest;

<time>
    <dtstart>1997… …

instead of

<time dtstart=”1997…

Of course the “real” iCal solution would be to continue with the entire time
recurrence declared as RECUR property values just as they are in 2445;

<time switch>
    <dtstart>1997…
       <RRULE>FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13…

In other words sticking to the value method used by iCal.

I have been planning  to do a map between the date-time value types of 2445
and those of XML-schemas (also a ISO8601 derivative, but that is WIP.  If
any one else has done that it would be nice to see it on the list –
otherwise I will proceed.

Greg