headers
Bernard Desruisseaux | 1 Feb 2002 01:09

Re: VCARs - any other specific proposals?


Doug Royer wrote:
> 
> As we are inventing VCARs and VQUERYs (2445 did not), it is
> not too late to do that. I am okay with multiple NAME's
> per VCAR, but only if they have unique LANGUAGE parameters.

I agree.

Where should we specify that multiple instances of the NAME
property, within a given component, MUST NOT have the same
value for their LANGUAGE parameter?  In the text?  In a
comment in the ABFN?  TZNAME didn't have this restriction
in RFC 2445.  But yes we should specify it.

Regards,
Bernard
--

-- 
Bernard Desruisseaux                    mailto:bernard <at> steltor.com
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878
Permalink | Reply | 1 comment |
headers
Doug Royer | 1 Feb 2002 01:28

Re: CAP: LANGUAGE parameter

Bernard Desruisseaux wrote:
> 
> Doug Royer wrote:
> >
> > And would you agree this is a separate issue from CAP?
> > I don't think that CAP cares, so this would be a separate
> > draft on making 2445 more L18N'able.
> 
> We still need to make sure that extensions to iCalendar
> part of the CAP draft are localiz............able! :-)

True, but that is ADDING a new feature.  There is no requierment
that CAP allow for multiple instances of LANGUAGE in one
component. Just adding it would break an existing iTIP
implementation. We can't just add them at this point.

So you can't just add them in CAP. 

AND - CAP does currently allow for any component in any ONE
language. So we are I18N and I10N ready.

> The restriction tables should be changed to specify 0+
> for the following properties:
> 
>    COMMENT
>    CATEGORIES
>    NAME

That would have to be an update to iTIP and is out of scope
for CAP - and expect LOTS of resistance on that. I think it
(Continue reading)

Permalink | Reply | 1 comment |
headers
Doug Royer | 1 Feb 2002 01:31

Re: VCARs - any other specific proposals?

Bernard Desruisseaux wrote:
> 
> Doug Royer wrote:
> >
> > As we are inventing VCARs and VQUERYs (2445 did not), it is
> > not too late to do that. I am okay with multiple NAME's
> > per VCAR, but only if they have unique LANGUAGE parameters.
> 
> I agree.
> 
> Where should we specify that multiple instances of the NAME
> property, within a given component, MUST NOT have the same
> value for their LANGUAGE parameter?  In the text?  In a
> comment in the ABFN?

As long as it is documented I don't think it matters.

>  TZNAME didn't have this restriction
> in RFC 2445.  But yes we should specify it.

True - but TZNAME needed to as is valid to have multiple
copies with the same data - and that is bogus.
Attachment (Doug.vcf): text/x-vcard, 348 bytes
Permalink | Reply | 0 comments |
headers
Bernard Desruisseaux | 1 Feb 2002 02:00

Re: CAP: UPN (User Principal Name)


Doug Royer wrote:
> 
> Bernard Desruisseaux wrote:
> >
> > I would like to propose the following syntax and semantic
> > for UPN values that can be specified in the GRANT and DENY
> > properties in VCAR components for the purpose of authorization.
> 
> You have confused the REALM part of the UPN and called
> it 'from' realm below. They are not the same.

It was not my intent.  You might want to help me with my
English though!  Are users "in a realm", "part of a realm",
"of a realm"?

> >    OWNER       The owner of the VAGENDA in which the
> >                encapsulating VCAR is stored
> 
> It means you name is in the OWNER property of the VAGENDA - correct?

Correct.

> 
> >    NONOWNER    All users except the owner of the VAGENDA
> >                in which the encapsulating VCAR is stored
> 
> It means your name is NOT in the OWNER property of the VAGANDA -
> correct?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernard Desruisseaux | 1 Feb 2002 02:07

RFC-2445: Re: CAP: LANGUAGE parameter


Doug Royer wrote:
> 
> Bernard Desruisseaux wrote:
> 
> >
> > I agree that multiple instances may not be appropriate for some
> > properties but it is a pity that 2445 doesn't provide us with a
> > "proper" way of doing that.
> 
> We could invent something like ALT_LOCATION, ALT_SUMMARY, ...
> to mean alternate:
> 
>         LOCATION;LANGUAGE=fr_ca:Montréal
>         ALT_LOCATION;LANGUAGE=en:Montreal
> 
> It would not break iTIP.

ALT-LOCATION (with a '-' and not a '_') sounds good to me.

Regards,
Bernard
--

-- 
Bernard Desruisseaux                    mailto:bernard <at> steltor.com
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878
Permalink | Reply | 0 comments |
headers
Bernard Desruisseaux | 1 Feb 2002 02:33

Re: CAP: LANGUAGE parameter


Doug Royer wrote:
> 
> Bernard Desruisseaux wrote:
> >
> > Doug Royer wrote:
> > >
> > > And would you agree this is a separate issue from CAP?
> > > I don't think that CAP cares, so this would be a separate
> > > draft on making 2445 more L18N'able.
> >
> > We still need to make sure that extensions to iCalendar
> > part of the CAP draft are localiz............able! :-)
> 
> True, but that is ADDING a new feature.  There is no requierment
> that CAP allow for multiple instances of LANGUAGE in one
> component. Just adding it would break an existing iTIP
> implementation. We can't just add them at this point.
> 
> So you can't just add them in CAP.
> 
> AND - CAP does currently allow for any component in any ONE
> language. So we are I18N and I10N ready.
> 
> > The restriction tables should be changed to specify 0+
> > for the following properties:
> >
> >    COMMENT
> >    CATEGORIES
> >    NAME
(Continue reading)

Permalink | Reply | 0 comments |
headers
Patrice Lapierre | 1 Feb 2002 14:54

Re: Initial connection to CAP server?


  Using the search command with the calstore as the target and
the following query:

	SELECT RELCALID FROM VAGENDA WHERE OWNER = SELF()

Should return the calendar(s) owned by the user.

"Shannon J. Clark" wrote:
> 
> A question occurred to me about initial connections to a Calendar Server:
> 
> How does a user learn what their Calendar is? i.e. the first time a user
> connects to a given CS and validates identity in some manner - how do they
> learn what their Calendar Address is?
> 
> Shannon
> 
> Shannon J. Clark
> President - JigZaw, Inc
> 1.800.4.JIGZAW (454.4929)
> shannon <at> jigzaw.com
> www.jigzaw.com
Permalink | Reply | 4 comments |
headers
John Stracke | 1 Feb 2002 16:32

RE: CAP: LANGUAGE parameter


>Just a quick comment... how would you "know" which to use?

All of them are equivalent; you pick the one that best matches the user's 
locale.  I suppose, if you don't know the locale, you use the LOCATION 
instead of any of the ALT-LOCATIONs.

/===========================================================\
|John Stracke                   |Principal Engineer         |
|jstracke <at> incentivesystems.com  |Incentive Systems, Inc.    |
|http://www.incentivesystems.com|My opinions are my own.    |
|===========================================================|
|Sleep is for wimps--healthy, well-adjusted wimps, but wimps|
|nonetheless.                                               |
\===========================================================/
Permalink | Reply | 0 comments |
headers
John Stracke | 1 Feb 2002 16:28

Re: CAP: LANGUAGE parameter


>We could invent something like ALT_LOCATION, ALT_SUMMARY, ...
>to mean alternate:

Yeah, this would be a good approach.

/===============================================================\
|John Stracke                   |Principal Engineer             |
|jstracke <at> incentivesystems.com  |Incentive Systems, Inc.        |
|http://www.incentivesystems.com|My opinions are my own.        |
|===============================================================|
|Dave Barry for President! He'll Keep Dan Quayle. (OK, it's old)|
\===============================================================/
Permalink | Reply | 0 comments |
headers
John Stracke | 1 Feb 2002 16:34

Re: RFC-2445: Re: CAP: LANGUAGE parameter


>ALT-LOCATION (with a '-' and not a '_') sounds good to me.

Of course, we should specify that ALT-foo can appear more than once.

/===============================================================\
|John Stracke                   |Principal Engineer             |
|jstracke <at> incentivesystems.com  |Incentive Systems, Inc.        |
|http://www.incentivesystems.com|My opinions are my own.        |
|===============================================================|
|Campbell's has it wrong--it's "Never underestimate the power of|
|*chocolate*".                                                  |
\===============================================================/
Permalink | Reply | 0 comments |

Gmane