headers
Lowde, Chris A | 1 Oct 1997 12:34
Favicon

RE: CONTACT Property For iCalendar

Frank,

If you are going to add this, and I believe that it looks like a useful
addition to the spec then it needs to be more functional than just a
text description.  As it stands I could not open a task and then have a
dialer Dial the number for me, as it may not be possible to parse the
phone number, or pager number from the string.

Therefore I propose that the definition is changed a little:

	CONTACT:Name=Jim Dolittle;ADDR= ABC
Industries;PHONE:VOICE=+1-919-555-1234;PHONE:PAGER=1-800-759-7243#123456
78

This has added advantage as I can send a ToDo to another person saying
call this person, and here is the number

	Actually we may need a Begin CONTACT, End CONTACT pair to do
this properly as what we may be embedding is the contents of a VCARD, so
thinking this out while typing, why not permit a BEGIN VCARD, END VCARD
to be placed in the ToDo, Journal, and  VEvent objects.

Chris Lowde
Texaco.

> -----Original Message-----
> From:	Earthlink [SMTP:fdawson <at> earthlink.net]
> Sent:	Tuesday, September 30, 1997 16:14
> To:	IETF Calendaring & Scheduling Mail List
> Subject:	CONTACT Property For iCalendar
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lars Lindegren | 1 Oct 1997 15:24
Picon

New Calendaring & Scheduling System

We are developers of an 16 bit Windows Client, Oracle/SQL
Server/Informix/Sybase database server Calendar.

We are now starting to completely rewrite it to a 32 bit version (first
Windows then Java Client), we would like it to confirm to as much
standards as possible.

You "manage" a great deal of Calendar standards. What do we do to
confirm to these standards, where do we get information, can we get help
(cooperation) from your organization, etc. ??

Regards

Lars Lindegren

D-House
+45 36 15 00 00
Fax +45 36 15 00 10
Attachment (vcard.vcf): text/x-vcard, 383 bytes
Permalink | Reply | 1 comment |
headers
Philippe Boucher | 1 Oct 1997 19:10
Picon

RE: CONTACT Property for iCalendar

Lowde, Chris A wrote:

> Frank,
>
> If you are going to add this, and I believe that it looks like a
useful
> addition to the spec then it needs to be more functional than just a
> text description.  As it stands I could not open a task and then have
a
> dialer Dial the number for me, as it may not be possible to parse the
> phone number, or pager number from the string.
>
> Therefore I propose that the definition is changed a little:
>
>         CONTACT:Name=Jim Dolittle;ADDR= ABC
>
Industries;PHONE:VOICE=+1-919-555-1234;PHONE:PAGER=1-800-759-7243#123456

> 78
>
> This has added advantage as I can send a ToDo to another person saying

> call this person, and here is the number
>
>         Actually we may need a Begin CONTACT, End CONTACT pair to do
> this properly as what we may be embedding is the contents of a VCARD,
so
> thinking this out while typing, why not permit a BEGIN VCARD, END
VCARD
> to be placed in the ToDo, Journal, and  VEvent objects.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Einar Stefferud | 2 Oct 1997 02:09

Re: iMIP Security- S/MIME

I know I am a few days tardy in this thread, but maybe I can help
anyway;-)...

It seems quite clear (to me) that this work is going to wind up
recycling through Proposed at least one extra time before it is ready
for progression to DRAFT status.  MHTML has goine through this recycle
and it has ben very ggood for the standard, but rather embarassing for
the WG Chair (namely me).

So, It seems to me that indeed you can mandate the Framework in this
round, which means that you make MIME Secure Multipart a clear
statement of direction and mandate that all security protocol must use
it along with some chosen other protocol that meets its requirements.

Thsi lets eveyone start to implement and to do some testing, while the
rest of the world bangs on the OpenPGP-S/MIME War Machines until they
turn into PlowShares, and CALSCH can then recycle at Proposed and get
on with its work.

You can even put an editorial note in the text to explain why this is
happening and what the expected outcome might be.

Seems to me that you can clearly agree on this much for now, and at
the same time add a bit of a nudge to the openPGP adn S/<IME
competition.

My logic stems from a clear concept that iTIP and iMIP should both use
the same security mechanisims if at all possible, adn that we have all
agreed that all CALSCH Protocol Data Units (PDUs) will be cast as MIME
types with parameters.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lowde, Chris A | 2 Oct 1997 07:34
Favicon

RE: CONTACT Property For iCalendar

Frank,

Referencing a URL makes the assumption that I am connected to the
internet and able to resolve the URL.  For the vast majority of users
this will not be true, and even for the next couple of years may not be
true.  I am currently sitting in an Hotel Room and although I am picking
up EMail via a phone line may not want to connect to the Internet just
to dial a number on a ToDo that you mailed me.  If I look to my
corporate users, we have many people who are working from laptops or in
offices that are only partially connected to the corporate WAN.  Not
because we don't want them to be connected, but because it is not
economically viable, or possible.  We have locations in many parts of
the world where telecommunications is severely challenged, and that
includes some parts of the US.  Not all places have T1 lines permanently
connected to their office.  
Further on in my message that you are quoting from I said that it would
be useful to embed a vCard within the ToDo.  This, from my point of
view, would be the preferable route, and because it is a vCard should
overcome your objection to redefining what is already a standard, after
all an embedded vCard would have to follow the vCard standard or it
wouldn't be a vCard!
Having read the message from Phillipe Boucher as well, I could agree to
a Multipart MIME message an included vCard and the ToDO having
CONTACT;VALUE=url if and only if the URL pointed to the attached vCard.
This also implies that the transmitting application has to have the
ability to attach the vCard to the ToDo.  If the transmitting app is not
capable of multi-part Mime then we will be back to embedding!

Chris
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lowde, Chris A | 2 Oct 1997 07:34
Favicon

RE: Todo Enhancement Proposal

I agree with Frank, a simple integer is more than adequate.

> -----Original Message-----
> From:	Frank Dawson [SMTP:fdawson <at> earthlink.net]
> Sent:	Monday, September 29, 1997 10:46
> To:	Ken Shan; ietf-calendar <at> imc.org
> Subject:	Re: Todo Enhancement Proposal
> 
>  Ken Shan wrote, in part:
> 
> >Such an enhancement would be useful, but the property value should
> >probably be a floating-point number between 0 and 1, for the sake of
> >mathematical simplicity and generality with regard to number systems.
> 
> I disagree. The INTEGER value is simple and adequate for interpersonal
> C&S
> applications. "MORE" is the evil of "ADEQUATE" in this case.
> 
> - - Frank
>
Permalink | Reply | 0 comments |
headers
John W. Noerenberg | 2 Oct 1997 15:58

Re: iMIP Security- S/MIME

At 5:09 PM -0700 10/1/97, Einar Stefferud wrote:
>I know I am a few days tardy in this thread, but maybe I can help
>anyway;-)...

I'm in the same boat, Stef.   Desparately trying to catch up with a month's
worth of reading.

The model needs two things:

1) a secure methodology for exchanging objects across an unsecure net.
This is orthogonal to whether or not a specific link is secured.  Thus iRIP
and iMIP should use the same methodology.

2) an authentication methodology so that senders and receivers may
determine their rights to manipulate that information.

So far this discussion has focused on 1).  So I'll limit myself to that for
the present.

With regard to the discussion of the different MIME encapsulations for
securing objects, 1847 yields a framework, but the implementation (MOSS)
has a low probability of wide acceptance.  This seems like a bad choice.

2015 (PGP/MIME) is PROPOSED, but has some problems.  However, my reading of
OpenPGP is that they are not terribly difficult to fix. (You all should
understand I have a certain level of commitment to making that a true
statement).  We may be able to make the necessary changes w/o requiring a
whole new draft.  The problems in the draft have certainly NOT prohibited
implementations.  I think we can safely reference 2015, and not fear
greatly upsetting our timetable.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John W. Noerenberg | 2 Oct 1997 18:12

Re: New Calendaring & Scheduling System

At 2:24 PM +0100 10/1/97, Lars Lindegren wrote:
>We are developers of an 16 bit Windows Client, Oracle/SQL
>Server/Informix/Sybase database server Calendar.
>
>We are now starting to completely rewrite it to a 32 bit version (first
>Windows then Java Client), we would like it to confirm to as much
>standards as possible.
>
>You "manage" a great deal of Calendar standards. What do we do to
>confirm to these standards, where do we get information, can we get help
>(cooperation) from your organization, etc. ??

This could easily become your organization, as well.  The only requirement
to being an IETF "member" is to actively participate in the working group
mailing lists.  Please read the draft protocols that are under the purview
of the CALSCH working group.  An easy place to find references to them all
is the WG charter page:
<http://www.ietf.org/html.charters/calsch-charter.html>.  That page
contains references to all the current protocol proposals, as well as
pointers to the WG archive (stored at the Internet Mail Consortium
<http://www.imc.org>).

Your comments, suggestions, and most of all, your participation in the
development of these protocols is most welcome, and most important to their
taking their place as standards of the Internet.

best,

john noerenberg
jwn2 <at> qualcomm.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Harald.T.Alvestrand | 5 Oct 1997 22:23
Picon
Picon

Re: iMIP Security- S/MIME

Let me add my voice to Stef's about one thing:

A recycle at Proposed is not a big thing.
It is highly unusual that something is 100% right the first time around,
at least anything of any complexity (and Calsch is NOT simple).
We make the best effort we can this round, and if we're wrong,
we're wrong, and must try again.

Have fun!

                 Harald A
Permalink | Reply | 0 comments |
headers
Philippe Boucher | 7 Oct 1997 20:45
Picon

Re: CONTACT Property For iCalendar

Hello everyone

Lowde, Chris A wrote:

> Frank,
>
> Referencing a URL makes the assumption that I am connected to the
> internet and able to resolve the URL.  For the vast majority of users
> this will not be true, and even for the next couple of years may not be
> true.  I am currently sitting in an Hotel Room and although I am picking
> up EMail via a phone line may not want to connect to the Internet just
> to dial a number on a ToDo that you mailed me.  If I look to my
> corporate users, we have many people who are working from laptops or in
> offices that are only partially connected to the corporate WAN.  Not
> because we don't want them to be connected, but because it is not
> economically viable, or possible.  We have locations in many parts of
> the world where telecommunications is severely challenged, and that
> includes some parts of the US.  Not all places have T1 lines permanently
> connected to their office.

Following this argument, you would also need a way to embed other things
too, like attachments.   I think this leads us back eventually to using MIME
since you
can use it to encode whatever you want from vcards to gifs to wordperfect
documents.
I dont think that it should be the job of iCalendar to deal with problems
like bad
communication lines.  iCalendar should just address the problem of
representing
calendaring information and leave things  like insufficient lines of
(Continue reading)

Permalink | Reply | 0 comments |

Gmane