Apple iCal & cosmo-demo

Can you clarify option 1? No HTTPS at all or no HTTPS for
iCAL? If no 
HTTPS for iCAL how would Cosmo know it is serving an iCAL
client? And 
then would it issue a re direct for every CalDAV call made
my the 
client? This seems to be very resource intensive.
As for not having HTTPS at all, I would think that not
having HTTPS 
would be a detractor to cosmo adoption as a public (ie in
the DMZ) service.

Option 2 means that any changes you do have to be done three
times. Or 
at least I am assuming that not having looked to deeply into
the code. 
As someone mentioned earlier on this thread, having this
multiple client 
issue is like all the pain of supporting multiple browsers.
Also I don't know if having 3 urls is even a viable option.
Someone more 
familiar with Cosmo will need to speak to that.

Just my 2 cents. 




Sheila Mooney wrote:
> So it looks like we have a couple of options if we want
to make this 
> work.
>
> 1. We could just do http and not https.
> 2. We could continue to offer access over http, and
give users 3 urls, 
> 1 for ical specifically.
>
> Could someone comment on the technical tradeoffs for
both solutions? 
> For example, what is the downside if we use http (port
80) rather than 
> https?
>
> Thanks,
> Sheila
>
> On Mar 7, 2006, at 10:49 AM, Morgen Sagen wrote:
>
>>
>> On Mar 7, 2006, at 9:31 AM, Charles Wyble wrote:
>>
>>>
>>>
>>> Lisa Dusseault wrote:
>>>>
>>>> On Mar 6, 2006, at 12:17 PM, Morgen Sagen
wrote:
>>>>
>>>>> I don't think Chandler should assume
that there will be a port 80 
>>>>> ('http') server along with the port
443 ('https') server, and that 
>>>>> they both refer to the same Cosmo
instance.  I'm not sure how 
>>>>> Chandler could know this in a general
way, without having 
>>>>> site-specific logic (in other words,
"if host == 'cosmo-demo' then 
>>>>> port 443 is equivalent to 80")
inside Chandler.  It's perhaps 
>>>>> unusual that cosmo-demo is set up this
way, and I wouldn't count 
>>>>> on it.  I would be interested to hear
what other people think.
>>> Well this isn't entirely true. Its not
Chandler thats the problem 
>>> but Apple ICAL. They evidently don't support
https. So the logic 
>>> would actually need to be inside Cosmo no? To
detect the client and 
>>> do different things.
>>
>> Well, yes and no.  It affects Chandler because we
have a feature 
>> which allows you to copy a shared collection's URL
to the clipboard 
>> so that you can paste it into either an email
message (to invite 
>> someone to subscribe) or to another client (such as
iCal).  The 
>> original question was if Chandler could somehow
generate the 'iCal 
>> friendly' URL in this situation, and I think it's
unfortunately 'no' 
>> since it's unlikely there *will* be such a
non-HTTPS URL (although 
>> there happens to be one now on cosmo-demo, which
was news to me).
>>
>> It is really unfortunate Apple removed HTTPS
support for iCal (which 
>> apparently happened quite recently).  I guess we
have to ask 
>> ourselves if we want to just use regular HTTP (port
80) rather than 
>> HTTPS.
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation
"Dev" mailing list
>> h
ttp://lists.osafoundation.org/mailman/listinfo/dev
>

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On Mar 15, 2006, at 10:29 AM, Charles Wyble wrote:

>
> Can you clarify option 1? No HTTPS at all or no HTTPS
for iCAL? If  
> no HTTPS for iCAL how would Cosmo know it is serving an
iCAL  
> client? And then would it issue a re direct for every
CalDAV call  
> made my the client? This seems to be very resource
intensive.
> As for not having HTTPS at all, I would think that not
having HTTPS  
> would be a detractor to cosmo adoption as a public (ie
in the DMZ)  
> service.

By #1 I meant turn off port 443.  I don't really like this.

> Option 2 means that any changes you do have to be done
three times.

No, changes would only have to be published once. There
would only be  
one Cosmo instance running, but it would be listening to
port 80 and  
port 443.  I don't like this either because what's the
point of using  
port 443 (HTTPS) if you're going to allow port 80 (HTTP)? 
Other than  
during development I mean -- it's very useful to be able to
watch  
Chandler/Cosmo chat over port 80 for debugging purposes.

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

So it looks like either of these options aren't great. Are
there any  
others we should be considering (other than punting on this
use case  
altogether)?

On Mar 15, 2006, at 10:53 AM, Morgen Sagen wrote:

>
> On Mar 15, 2006, at 10:29 AM, Charles Wyble wrote:
>
>>
>> Can you clarify option 1? No HTTPS at all or no
HTTPS for iCAL? If  
>> no HTTPS for iCAL how would Cosmo know it is
serving an iCAL  
>> client? And then would it issue a re direct for
every CalDAV call  
>> made my the client? This seems to be very resource
intensive.
>> As for not having HTTPS at all, I would think that
not having  
>> HTTPS would be a detractor to cosmo adoption as a
public (ie in  
>> the DMZ) service.
>
> By #1 I meant turn off port 443.  I don't really like
this.
>
>> Option 2 means that any changes you do have to be
done three times.
>
> No, changes would only have to be published once. There
would only  
> be one Cosmo instance running, but it would be
listening to port 80  
> and port 443.  I don't like this either because
what's the point of  
> using port 443 (HTTPS) if you're going to allow port
80 (HTTP)?   
> Other than during development I mean -- it's very
useful to be able  
> to watch Chandler/Cosmo chat over port 80 for debugging
purposes.
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation
"chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chan
dler-dev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On 3/15/06, Morgen Sagen <morgenosafoundation.org>
wrote:

> No, changes would only have to be published once. There
would only be
> one Cosmo instance running, but it would be listening
to port 80 and
> port 443.  I don't like this either because what's
the point of using
> port 443 (HTTPS) if you're going to allow port 80
(HTTP)?  Other than
> during development I mean -- it's very useful to be
able to watch
> Chandler/Cosmo chat over port 80 for debugging
purposes.

just to clarify, morgen is talking about an osaf-run
instance of
cosmo, not the basic software product itself.
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

I could see people wanting read+write over HTTPS, while
allowing read- 
only over port 80. Can Cosmo be set up such that one
instance can  
serve more both ports, but only allowing read-only on port
80? I  
think anything more than that is beyond the scope of Cosmo,
really.

Reid

On Mar 15, 2006, at 13:53, Morgen Sagen wrote:
> On Mar 15, 2006, at 10:29 AM, Charles Wyble wrote:
>> Can you clarify option 1? No HTTPS at all or no
HTTPS for iCAL? If  
>> no HTTPS for iCAL how would Cosmo know it is
serving an iCAL  
>> client? And then would it issue a re direct for
every CalDAV call  
>> made my the client? This seems to be very resource
intensive.
>> As for not having HTTPS at all, I would think that
not having  
>> HTTPS would be a detractor to cosmo adoption as a
public (ie in  
>> the DMZ) service.
>
> By #1 I meant turn off port 443.  I don't really like
this.
>
>> Option 2 means that any changes you do have to be
done three times.
>
> No, changes would only have to be published once. There
would only  
> be one Cosmo instance running, but it would be
listening to port 80  
> and port 443.  I don't like this either because
what's the point of  
> using port 443 (HTTPS) if you're going to allow port
80 (HTTP)?   
> Other than during development I mean -- it's very
useful to be able  
> to watch Chandler/Cosmo chat over port 80 for debugging
purposes.

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On 3/15/06, Sheila Mooney <sheilaosafoundation.org>
wrote:
> So it looks like either of these options aren't great.
Are there any
> others we should be considering (other than punting on
this use case
> altogether)?

for cosmo-demo: i think we should allow both cleartext and
secure
access, and prominently document ical's behavior on the
cosmo-demo
front page so that cosmo users know to not use https.

for cosmo itself: i don't think we should make any code
changes. at
some point apple will resolve their issue and reintroduce
ssl support
into ical. at that point any ical-specific code we've
written will
become useless until we refine it to recognize specific
versions of
ical (assuming that's even possible). don't want to go
there.
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

Hello,

Brian Moseley wrote:
> for cosmo-demo: i think we should allow both cleartext
and secure
> access, and prominently document ical's behavior on
the cosmo-demo
> front page so that cosmo users know to not use https.
> 

This would be very useful for those of us who
can't setup and maintain a Cosmo server just
yet but would like to try out Cosmo.

I think Brian's suggestion is fair, but if
security is still a concern then there can be
a per-user 'Allow Plaintext' flag that can be
set to false by default maybe?  The user
would actually have to 'turn on' plaintext
connections.

Best Regards,
Kervin
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On 3/15/06, Kervin L. Pierre <kervinadevsoft.com> wrote:

> This would be very useful for those of us who
> can't setup and maintain a Cosmo server just
> yet but would like to try out Cosmo.

agree with kervin and morgen. jared, are you listening? 

> I think Brian's suggestion is fair, but if
> security is still a concern then there can be
> a per-user 'Allow Plaintext' flag that can be
> set to false by default maybe?  The user
> would actually have to 'turn on' plaintext
> connections.

i'd prefer to wait until i am overwhelmed by the clamor of
many users
shouting for this feature 
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On 3/15/06, Reid Ellis <raeosafoundation.org>
wrote:
> I could see people wanting read+write over HTTPS, while
allowing read-
> only over port 80. Can Cosmo be set up such that one
instance can
> serve more both ports, but only allowing read-only on
port 80? I
> think anything more than that is beyond the scope of
Cosmo, really.

it is technically possible, but i think even that is not
likely to
happen within cosmo anytime soon, since it can be easily
done at a
layer in front of cosmo for those who have such advanced
needs.
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On Mar 15, 2006, at 12:14 PM, Brian Moseley wrote:

> On 3/15/06, Sheila Mooney <sheilaosafoundation.org> wrote:
>> So it looks like either of these options aren't
great. Are there any
>> others we should be considering (other than punting
on this use case
>> altogether)?
>
> for cosmo-demo: i think we should allow both cleartext
and secure
> access, and prominently document ical's behavior on
the cosmo-demo
> front page so that cosmo users know to not use https.
>
> for cosmo itself: i don't think we should make any
code changes. at
> some point apple will resolve their issue and
reintroduce ssl support
> into ical. at that point any ical-specific code we've
written will
> become useless until we refine it to recognize specific
versions of
> ical (assuming that's even possible). don't want to
go there.

I agree that we should just document how to get around
iCal's current  
behavior.  Otherwise we would have to add code to Chandler
equivalent  
to:

  "if we've just published a collection to this
specific host (cosmo- 
demo.osafoundation.org) over port 443, then return three
URLs ***,  
otherwise return two **."

I don't see any other technical solution that doesn't
require Cosmo  
to communicate the fact that there happens to be another
port open  
that points to the same instance.  Let's just document this
and move  
on.  There are more important issues to deal with.  

~morgen

*** Three URLs: an https/read-write, an https/read-only, and
a http/ 
read-only
** Two URLs: a read/write and a read/only, using whatever
port was  
used for publishing
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev