From subs-reminder@imc.org Mon Dec 2 20:22:01 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20721 for ; Mon, 2 Dec 2002 20:22:00 -0500 (EST) From: subs-reminder@imc.org Received: (from phoffman@localhost) by above.proper.com (8.11.6/8.11.3) id gB31Oi403865; Mon, 2 Dec 2002 17:24:44 -0800 (PST) Date: Mon, 2 Dec 2002 17:24:44 -0800 (PST) Message-Id: <200212030124.gB31Oi403865@above.proper.com> To: calsch-archive@ietf.org Subject: [[966778556]] Subscription to ietf-calendar for calsch-archive@lists.ietf.org Greetings. This message is a periodic reminder that calsch-archive@lists.ietf.org is subscribed to the ietf-calendar mailing list. There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-calendar mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-calendar-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "calsch-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-calendar@mail.imc.org Wed Dec 4 15:29:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02384 for ; Wed, 4 Dec 2002 15:29:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB4KGS622135 for ietf-calendar-bks; Wed, 4 Dec 2002 12:16:28 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4KGOg22125 for ; Wed, 4 Dec 2002 12:16:24 -0800 (PST) In-Reply-To: <3DD91C19.4000903@Royer.com> To: ietf-calendar@imc.org Subject: Re: CAP ABNF and external references MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 4 Dec 2002 15:15:58 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 12/04/2002 03:16:20 PM, Serialize complete at 12/04/2002 03:16:20 PM Content-Type: multipart/alternative; boundary="=_alternative 006F60DD85256C85_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006F60DD85256C85_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 11/18/2002 11:58:01 AM: > > Im sorry I wasnt a bit more clear in my original posting; this change is > > probably not sufficient. The definition/ABNF for integer in RFC 2445 is: > > > > integer = (["+"] / "-") 1*DIGIT > > > > Description: If the property permits, multiple "integer" values are > > specified by a COMMA character (US-ASCII decimal 44) separated list > > of values. The valid range for "integer" is -2147483648 to > > 2147483647. If the sign is not specified, then the value is assumed > > to be positive. > > > > As such it is valid to have negative or "0" LATENCY. I think CAP should > > adopt the BEEP approach of expressly defining a range of allowed values > > ala: > > And how does a positive integer like the following that I > sent go negative? > > p-integer = 1*DIGIT ; Where DIGIT is defined in [iCAL] The p-integer definition does not go negative. I _never_ said it did, go reread my post; Im talking about integer from 2445! However your new p-integer does allow for 0 which is still a non-useful value for LATENCY. Whats wrong w/redefining as I suggested: latency-sec = 1..2147483647 (I think I put in 0.. before but I didnt mean to.) I dont see a pressing need to define p-integer since A) it leaves the maximum value undefined in the ABNF and B) very large values like those possible from integer in 2445 (~68 YEARS) are not that useful for C/S (no matter how robust you think your implementation is, I strongly doubt anyone would wait that long for a single command to complete!!) Im advocating the KISS approach and defining strict limits to the latency-sec that are sufficent for nearly any needs. A maximum value of 86400 is probably more than enough for any CAP command; its equivalent to 24 hours given that latency-sec is in units of seconds. Thus I ammend my proposal to be that we redefine latency-sec as: latency-sec = 1..86400 and this precludes overly long timeouts and the 'What is a 0 time out?' case. > > I guess this raises some questions about LATENCY since its not clearly > > defined in the draft (there is only some ABNF but no prose about > > limitations, etc): > > > > 1) If there is no LATENCY= (and ACTION=) params on a command, does it > > ever time out? > > A) If not then we need to clearly say this in the draft and provide > > the CS some clear way to 'error out' after processing the command ("You > > have exceeded the maximum allowable time for a single command, try again > > later or simplify the command and arguments.") > > We do - send a VREPLY with an error. The entire argument for LATENCY > way back in the iRIP time frame was so that you could specify > a timeout. The presumption being that you have no timeout if > you do not sent one. > > I see NO need to have LATENCY to specify timeout and ANOTHER-LATENCY > to specify the timeout when LATENCY is not specified. You didnt answer the question, you were strictly responding to the (A) possible answer case. Nowhere in CAP 09-submitted can I find ANY text that clearly states if a command ever times out if _no_ LATENCY and ACTION parameters are present on the command. Are you suggesting that the command never times out (perhaps unless the CS decides to error out for some reason like the command is taking too many system resource, etc)? Or are you saying that all commands time out even if no LATENCY / ACTION parameters are provided?? Hmm, perhaps you did with that last line of the 1st paragraph but its _NOWHERE_ in CAP so its ambiguous as to how an implemenatation should address the case of no LATENCY and ACTION parameters... In the interest of clearning this up why not mandate the following: 1) LATENCY MUST always be provided, ACTION MUST be provided except for the case outlined in 2) below 2) If no timeout is desired/intended then a value of '0' MUST be used for LATENCY and ACTION MUST NOT appear (since no ACTION is required if no timeout is to occur). 3) If any timeout is desired/intended then a value between 1..86400 MUST be used for LATENCY and ACTION MUST appear. Im just trying to find ambiguities or vagaries in the spec and get rid of them. > > 2) What good is LATENCY=0 on a command if the lack of the LATENCY > > parameter effectively means "Never times out"? > > I could argue that it is a good way to perform a DOS on a CS :-) > > I agree - lets disallow LATENCY of zero, as '1' would never > be a issue :-) Well there is little difference between using LATENCY=0 for a DOS and sending NO LATENCY at all; apart from 9 octets of extra data in the former case (excluding the required ACTION=... parameter too). I didnt propose we disallow '0', I just asked what good it was given the current ABNF. I could go either way with LATENCY=0 or no LATENCY parameter; I just want it to be clearly defined in the draft what it means to have no LATENCY (if we go the route of no LATENCY means "this command never times out" or not). If LATENCY is optional then we need to be clear on what it means to not be there. If LATENCY is not optional then using '0' for "never times out" is the route to go. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006F60DD85256C85_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 11/18/2002 11:58:01 AM:
> > Im sorry I wasnt a bit more clear in my original posting; this change is
> > probably not sufficient.  The definition/ABNF for integer in RFC 2445 is:
> >
> >      integer    = (["+"] / "-") 1*DIGIT
> >
> >     Description: If the property permits, multiple "integer" values are
> >     specified by a COMMA character (US-ASCII decimal 44) separated list
> >     of values. The valid range for "integer" is -2147483648 to
> >     2147483647. If the sign is not specified, then the value is assumed
> >     to be positive.
> >
> > As such it is valid to have negative or "0" LATENCY.  I think CAP should
> > adopt the BEEP approach of expressly defining a range of allowed values
> > ala:
>
> And how does a positive integer like the following that I
> sent go negative?
>
>       p-integer   = 1*DIGIT  ; Where DIGIT is defined in [iCAL]
The p-integer definition does not go negative.  I _never_ said it did, go reread my post;  Im talking about integer from 2445!  However your new p-integer does allow for 0 which is still a non-useful value for LATENCY.

Whats wrong w/redefining as I suggested:

   latency-sec = 1..2147483647

(I think I put in 0.. before but I didnt mean to.)  I dont see a pressing need to define p-integer since A) it leaves the maximum value undefined in the ABNF and B) very large values like those possible from integer in 2445 (~68 YEARS) are not that useful for C/S (no matter how robust you think your implementation is, I strongly doubt anyone would wait that long for a single command to complete!!)

Im advocating the KISS approach and defining strict limits to the latency-sec that are sufficent for nearly any needs.  A maximum value of 86400 is probably more than enough for any CAP command; its equivalent to 24 hours given that latency-sec is in units of seconds.  Thus I ammend my proposal to be that we redefine latency-sec as:

   latency-sec = 1..86400

and this precludes overly long timeouts and the 'What is a 0 time out?' case.

> > I guess this raises some questions about LATENCY since its not clearly
> > defined in the draft (there is only some ABNF but no prose about
> > limitations, etc):
> >
> > 1) If there is no LATENCY= (and ACTION=) params on a command, does it
> > ever time out?
> >     A) If not then we need to clearly say this in the draft and provide
> > the CS some clear way to 'error out' after processing the command ("You
> > have exceeded the maximum allowable time for a single command, try again
> > later or simplify the command and arguments.")
>
> We do - send a VREPLY with an error. The entire argument for LATENCY
> way back in the iRIP time frame was so that you could specify
> a timeout. The presumption being that you have no timeout if
> you do not sent one.
>
> I see NO need to have LATENCY to specify timeout and ANOTHER-LATENCY
> to specify the timeout when LATENCY is not specified.
You didnt answer the question, you were strictly responding to the (A) possible answer case.

Nowhere in CAP 09-submitted can I find ANY text that clearly states if a command ever times out if _no_ LATENCY and ACTION parameters are present on the command.  Are you suggesting that the command never times out (perhaps unless the CS decides to error out for some reason like the command is taking too many system resource, etc)?  Or are you saying that all commands time out even if no LATENCY / ACTION parameters are provided??

Hmm, perhaps you did with that last line of the 1st paragraph but its _NOWHERE_ in CAP so its ambiguous as to how an implemenatation should address the case of no LATENCY and ACTION parameters...

In the interest of clearning this up why not mandate the following:

1) LATENCY MUST always be provided, ACTION MUST be provided except for the case outlined in 2) below
2) If no timeout is desired/intended then a value of '0' MUST be used for LATENCY and ACTION MUST NOT appear (since no ACTION is required if no timeout is to occur).
3) If any timeout is desired/intended then a value between 1..86400 MUST be used for LATENCY and ACTION MUST appear.

Im just trying to find ambiguities or vagaries in the spec and get rid of them.  

> > 2) What good is LATENCY=0 on a command if the lack of the LATENCY
> > parameter effectively means "Never times out"?
>
> I could argue that it is a good way to perform a DOS on a CS :-)
>
> I agree - lets disallow LATENCY of zero, as '1' would never
> be a issue :-)
Well there is little difference between using LATENCY=0 for a DOS and sending NO LATENCY at all; apart from 9 octets of extra data in the former case (excluding the required ACTION=... parameter too).

I didnt propose we disallow '0', I just asked what good it was given the current ABNF.  I could go either way with LATENCY=0 or no LATENCY parameter; I just want it to be clearly defined in the draft what it means to have no LATENCY (if we go the route of no LATENCY means "this command never times out" or not).  If LATENCY is optional then we need to be clear on what it means to not be there.  If LATENCY is not optional then using '0' for "never times out" is the route to go.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 006F60DD85256C85_=-- From owner-ietf-calendar@mail.imc.org Wed Dec 4 16:19:55 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04314 for ; Wed, 4 Dec 2002 16:19:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB4LATk24643 for ietf-calendar-bks; Wed, 4 Dec 2002 13:10:29 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4LARg24639 for ; Wed, 4 Dec 2002 13:10:27 -0800 (PST) In-Reply-To: <3DD922D7.8070902@Royer.com> To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 4 Dec 2002 16:10:24 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 12/04/2002 04:10:19 PM, Serialize complete at 12/04/2002 04:10:19 PM Content-Type: multipart/alternative; boundary="=_alternative 00745C9885256C85_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00745C9885256C85_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 11/18/2002 12:26:47 PM: > > Kinda illogical to me. > > If the command succeeded then I should be allowed in. > > Where does the draft say that if it succeeds that you are not allowed in? Go reread BEEP where it talks about this apparent paradox. See Section 3.1.1 Profile Identification and Initialization. Its not 100% a 1-to-1 mappable example to CAP but its a scenario where it can occur. In any case the main topic here is the way CAP deals with failures, etc. > If you determined that a hacker was attacking your system, would > you first inform them: > > > 1: Network failure > > 2: CS crash/shutdown > > 3: "Im a bad boy" > > 4: "Im not allowed to be the CFO of the company" > > 5: "Sorry C&S Team AA, you are still not allowed to assume Bruces identity" > > ... Hmm, Im impressed that you alone have developed the means to make software clairvoyant and have imbued it with the ability to tell a hacker from a legitimate user who is retrying something they think should/will work. I look forward to reading the patent application for that. The "dealing with a hacker" case is just one scenario. The responses you gave for 2, 4 and 5 are VERY useful for informing legitimate users of failures for assorted reasons (the CUA and CS disagree on authorization, credentials, etc). If the CS thinks its got a hacker then 3 is probably the best answer to send back. You are arguing FOR my points here, not against them. Sounds like violent agreement again... > Or would you just block them? I block them and let them wonder why they > failed. "Security thru obscurity" went out in the early 90's around here... Perhaps its still alive elsewhere in the world though. > I would not inform them of the specifics. And we are talking > about a 'security violation' and NOT a failed login attempt. No matter the case. In your scenario the hacker logged in just fine and is now attempting to get to areas they are not permitted. In other scenarios its AAs trying to do the same thing but they are prohibited for some reason (ie: Credential discrepancies, etc). My point is that there are many valid cases where providing information IS desirable but we have no way to do it. If your implementation decides that a persistent AA is a hacker then its free to send back a (3) response and drop them entirely. You can even have the CS lock that UPN out (or the IP out or both or...). I dont think we should design CAP with the mind set that all CUAs that try to do thinks that fail are hackers; thats just a negative mindset that impedes usability designs in the protocol. > > So just how would you craft your awesome CUA so that it can distinguish > > between the cases listed above?? I dont see anything in the CAP draft > > that would allow it so you must have some pretty good mojo to do it w/o > > protocol support... > > If a CUA attempts to hack my system - I would not care about the error > messages it displayed. Again w/the clairvoyance references... You still dont address dealing w/the CUA before you get to this determination (unless you consider 1 failure a hack attack and punt them right off!). For these cases how does the CUA know that the failure is due to insufficient credentials, the CS beginning shutdown, etc. if its not sent by the CS?? > > You are assuming that the CS did some diagnostic logging at a minimum. > > That BEEP-like recomendation should be added to the draft since its not > > there now. > > Where does it say that the CS may not perform logging as specified > and recommended in BEEP? CAP logging is not the same as BEEP logging. BEEP logging should be for stuff like bad BEEP packets, etc. CAP logging would be for failures like we are arguing now. The inability to change the identity is NOT a BEEP level issue; its a CAP one. Im recommending that CAP include some text ala BEEPs for cases like this since there is _none_ now. > > Im NOT trying to nail down what criteria a CS uses to determine if the > > IDENTIFY command is an actual violation or not; Im just trying to nail > > down the behaviour so that its a bit more robust and allows for > > providing of diagnostic information when/if the implementation desires > > to send it. > > I will never tell a hacker or malicious software why attempts failed. So just send back a (3) "Bad boy" response and punt them. Until they get to that point though you should be sending back some more useful response codes so that legit CUAs can take the right course of action besides complaining to the boss "That stupid program wont let me and I cant tell why!". Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00745C9885256C85_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 11/18/2002 12:26:47 PM:
> >  Kinda illogical to me.
> >  If the command succeeded then I should be allowed in.
>
> Where does the draft say that if it succeeds that you are not allowed in?
Go reread BEEP where it talks about this apparent paradox.  See Section 3.1.1 Profile Identification and Initialization.  Its not 100% a 1-to-1 mappable example to CAP but its a scenario where it can occur.  In any case the main topic here is the way CAP deals with failures, etc.

> If you determined that a hacker was attacking your system, would
> you first inform them:
>
>    > 1: Network failure
>    > 2: CS crash/shutdown
>    > 3: "Im a bad boy"
>    > 4: "Im not allowed to be the CFO of the company"
>    > 5: "Sorry C&S Team AA, you are still not allowed to assume Bruces identity"
>    > ...
Hmm, Im impressed that you alone have developed the means to make software clairvoyant and have imbued it with the ability to tell a hacker from a legitimate user who is retrying something they think should/will work.  I look forward to reading the patent application for that.

The "dealing with a hacker" case is just one scenario.  The responses you gave for 2, 4 and 5 are VERY useful for informing legitimate users of failures for assorted reasons (the CUA and CS disagree on authorization, credentials, etc).  If the CS thinks its got a hacker then 3 is probably the best answer to send back.

You are arguing FOR my points here, not against them.  Sounds like violent agreement again...

> Or would you just block them? I block them and let them wonder why they
> failed.

"Security thru obscurity" went out in the early 90's around here...  Perhaps its still alive elsewhere in the world though.

>          I would not inform them of the specifics. And we are talking
> about a 'security violation' and NOT a failed login attempt.
No matter the case.  In your scenario the hacker logged in just fine and is now attempting to get to areas they are not permitted.  In other scenarios its AAs trying to do the same thing but they are prohibited for some reason (ie: Credential discrepancies, etc).

My point is that there are many valid cases where providing information IS desirable but we have no way to do it.  If your implementation decides that a persistent AA is a hacker then its free to send back a (3) response and drop them entirely.  You can even have the CS lock that UPN out (or the IP out or both or...).  I dont think we should design CAP with the mind set that all CUAs that try to do thinks that fail are hackers; thats just a negative mindset that impedes usability designs in the protocol.

> > So just how would you craft your awesome CUA so that it can distinguish
> > between the cases listed above??  I dont see anything in the CAP draft
> > that would allow it so you must have some pretty good mojo to do it w/o
> > protocol support...
>
> If a CUA attempts to hack my system - I would not care about the error
> messages it displayed.
Again w/the clairvoyance references...

You still dont address dealing w/the CUA before you get to this determination (unless you consider 1 failure a hack attack and punt them right off!).  For these cases how does the CUA know that the failure is due to insufficient credentials, the CS beginning shutdown, etc. if its not sent by the CS??

> > You are assuming that the CS did some diagnostic logging at a minimum.
> >  That BEEP-like recomendation should be added to the draft since its not
> > there now.
>
> Where does it say that the CS may not perform logging as specified
> and recommended in BEEP?
CAP logging is not the same as BEEP logging.  BEEP logging should be for stuff like bad BEEP packets, etc.  CAP logging would be for failures like we are arguing now.  The inability to change the identity is NOT a BEEP level issue; its a CAP one.  Im recommending that CAP include some text ala BEEPs for cases like this since there is _none_ now.

> > Im NOT trying to nail down what criteria a CS uses to determine if the
> > IDENTIFY command is an actual violation or not; Im just trying to nail
> > down the behaviour so that its a bit more robust and allows for
> > providing of diagnostic information when/if the implementation desires
> > to send it.
>
> I will never tell a hacker or malicious software why attempts failed.
So just send back a (3) "Bad boy" response and punt them.  Until they get to that point though you should be sending back some more useful response codes so that legit CUAs can take the right course of action besides complaining to the boss "That stupid program wont let me and I cant tell why!".

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 00745C9885256C85_=-- From owner-ietf-calendar@mail.imc.org Wed Dec 4 16:22:34 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04440 for ; Wed, 4 Dec 2002 16:22:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB4LGpK24965 for ietf-calendar-bks; Wed, 4 Dec 2002 13:16:51 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4LGmg24960 for ; Wed, 4 Dec 2002 13:16:49 -0800 (PST) In-Reply-To: <20021118183341.GF74436@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 4 Dec 2002 16:16:46 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 12/04/2002 04:16:41 PM, Serialize complete at 12/04/2002 04:16:41 PM Content-Type: multipart/alternative; boundary="=_alternative 0074F1C585256C85_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0074F1C585256C85_= Content-Type: text/plain; charset="US-ASCII" Andrea responded on 11/18/2002 01:33:41 PM: > The more I think about it, the more I think an explicit BYE command > would be beneficial. I concur. The BEEP dropping of a session is at the transport level. CAP is at the application level so a command _is_ appropriate. After all, there may be CAP commands still in progress when the CUA decides to go away. It should do so first at the application level rather than at the transport or network levels. If the CS has commands its still processing then the BYE command should be prevented. Otherwise a nice clean disconnect can be done and BEEP shutdown done, etc. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0074F1C585256C85_= Content-Type: text/html; charset="US-ASCII"
Andrea responded on 11/18/2002 01:33:41 PM:
> The more I think about it, the more I think an explicit BYE command
> would be beneficial.
I concur.  The BEEP dropping of a session is at the transport level.  CAP is at the application level so a command _is_ appropriate.  After all, there may be CAP commands still in progress when the CUA decides to go away.  It should do so first at the application level rather than at the transport or network levels.

If the CS has commands its still processing then the BYE command should be prevented.  Otherwise a nice clean disconnect can be done and BEEP shutdown done, etc.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0074F1C585256C85_=-- From owner-ietf-calendar@mail.imc.org Wed Dec 4 17:50:33 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08299 for ; Wed, 4 Dec 2002 17:50:32 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB4Me5L01142 for ietf-calendar-bks; Wed, 4 Dec 2002 14:40:05 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4Me3g01138 for ; Wed, 4 Dec 2002 14:40:03 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gB4Me4C0023751 for ; Wed, 4 Dec 2002 14:40:04 -0800 Message-ID: <3DEE843F.5010909@Royer.com> Date: Wed, 04 Dec 2002 15:39:59 -0700 From: Doug Royer Reply-To: Doug@royer.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calendar@imc.org Subject: Re: 10.4 IDENTIFY Command II References: <3DEE7B7C.8080003@Royer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000608030307070403040101" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000608030307070403040101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sorry about my posts from the calendaring working group. I mis-configured my mailer - it's fixed now. -Doug --------------ms000608030307070403040101 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIwNDIyMzk1OVowIwYJKoZIhvcNAQkEMRYEFDFk4g7M zhCdFvXSkgLbK3CzbRsHMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCDEvl8kcXVWcrM2n78 8jYTjPgCsId1UuFHvrZ2fNK6UFsLUgpzEe+v27ElKRZQ6ZbOWGgM2GY5/vUh0kw2xxfdCc2K GxnvE5pLwRacaKSKz0c5Wzx10FqCdZ3LzV1S6sxZvrAlpSEuK3cpajskidNdMYNbqOCcVIfJ 0ZMhLEa45TNXQ1x1/1wmYz2UJIRw8VZvtpUQHYfQbPExxInZsMCcmwKyiV8f+4OQ0am327sZ 9irpSobv5pw/kWBCNiv2AUV3gsz/tNCNmcLuB2tc4/6V358nUpZZoqTs9DHlovc8NAT/+hJl Lwz9G0gI4WaQOAUw5oNSOm/gJ/ohadvB2lQ1AAAAAAAA --------------ms000608030307070403040101-- From owner-ietf-calendar@mail.imc.org Wed Dec 4 17:50:35 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08314 for ; Wed, 4 Dec 2002 17:50:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB4Mh8q01367 for ietf-calendar-bks; Wed, 4 Dec 2002 14:43:08 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4Mh5g01359 for ; Wed, 4 Dec 2002 14:43:06 -0800 (PST) In-Reply-To: <20021119114928.GM96286@inet.it> To: Andrea Campi Cc: ietf-calendar@imc.org Subject: Re: What good are stored VQUERYs? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Wed, 4 Dec 2002 17:43:03 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 12/04/2002 05:42:53 PM, Serialize complete at 12/04/2002 05:42:53 PM Content-Type: multipart/alternative; boundary="=_alternative 007CD82C85256C85_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007CD82C85256C85_= Content-Type: text/plain; charset="US-ASCII" Andrea wrote on 11/19/2002 06:49:29 AM: > Once again, I don't see the problem. If the CUA sends: > > BEGIN:VQUERY > QUERY:SELECT VQUERY FROM VAGNEDA WHERE NAME = 'MAGIC01' > ENV:VQUERY > > The CS replies: > > BEGIN:VQUERY > QUERYID:MAGIC01 > END:VQUERY > > I don't see why you think it should be an error (although it would require > an ABNF change) - the CS has the query so it sends what it has. It just > happens to be unable to represent it in CAP-QL. But the CS _DID_ represent it in CAP-QL. It just happens that the CAP-QL is 'empty' and thus not really presentable to the CU. The VQUERY is just a name, no actions or anything that can be used to present or describe it to a CU. As such this appears to be 'useless'; the knowledge that MAGIC01 is a canned non-CAP-QL query exists only at the CU level (above the CUA since there are no name spaces for VQUERYs to distinguish a CUAs MAGIC01 query from your CUA/CSs canned MAGIC01). I would prefer some CS response to retrieving the non-CAP-QL encodable query like "505 - Server unable to encode the requested data" since this is also more useful going forwards in any expansion to CAP we design later on. > Incidentally, that's the > reason why a few months ago I proposed we added a way to specify the VQUERY > is hardcoded in the CS and can't be represented in CAP-QL. > > BEGIN:VQUERY > QUERYID:MAGIC01 > NATIVE:YES (NATIVE is just an example, you can choose a better name) > END:VQUERY Kind of like the predefined VCARs but different in that its unencodable (currently) such that a CUA can retrieve it... I think Id prefer that all data be encodable (even if its by adding new properties, components, etc) rather than taking a flag approach as a CUA may still want to be able to retrieve and present the MAGIC01 query to the CU; after all we dont have namespaces on them so we could get into a hairy mess when your CUA uses MAGIC01 to my CS and a totally different action happens that is expected... > This would make clear to a CUA that it is looking at a valid VQUERY, but > nothing is know about its implementation - so the CUA had better know what > to do with it or leave it alone. We would need some kind of name space for this to work. See above. > Also, do you really expect all CUAs to retrieve the VQUERY before calling > it? Then what, do a string compare of the QUERY? It would be even less > useful then. As part of building a sync engine ALL components will have to be representable in a format that can be retrieved and pushed between 2 stores. Otherwise it wont be able to sync fully and opening the door for VQUERYs only is just inserting a tiny wedge that allow for justification of other non-encodable representations to develop in the future. Bad joss... > I agree that CAP should allow storing any component. Of course, an actual CUA > implementation should not expect to be able to store components the server > doesn't list as supported in GET-CAPABILITY. I concur w/the "expect" bit. I would hope that a CS would try to store unknown components in some blobular way such that the CS (Calendar _Store_) can act as a true Store for newer data w/o having to actually grok it fully. Nowhere does it say in CAP that a CS needs to be able to decypher the intent/meaning of a component; it only talks about how it should be represented for querys, etc. This has an implicit "any blob will work" mentality but thats just my take on the text. > > IMHO there should be no data put into the CS by ANY means (Administrative > > or not) that cannot be retrieved and/or encoded using the CAP 1.0 or > > updated iCalendar specs. Otherwise it just becomes a recipe for disaster. > > I agree. It just happens to have no QUERY property, so what? It's still > legal, so you can retrieve it. If the 'native' querys are not encodable in a VQUERY then they cannot be returned in one obviously. As such another means is necessary; a VQUERY2 or possible some other query mechanism and represenation. In any case I think we are pretty much in agreement on this and the other issues. > > response to the "SELECT VQUERY FROM VAGENDA ..." command. I would not > > expect a CUA to use a VQUERY that it cannot read from the CS, would you?? > > (I like to practice Save Hex...) > > That's a CUA choice. In controlled environments (the CUA knows it can > trust the CS), it would be safe. Remember that I'm talking about hardcoded > VQUERY, so no malicious CUA could change them. If the CUA got back the 'empty' VQUERY you had at top then its not unlikely that a CU may see that there is nothing in the query and try to either delete it or modify it for their use. The CUA _could_ prohibit this but again this gets back to the name space issue we have not addressed... > Since I seem to be the only one to defend it, I have no problem with taking > stored queries away and doing it properly in another draft. However, this > requires thinking NOW about how the new draft will extend the current > model. The replacement design would be to expressly codify how a CS deals with new component types (ie: VQUERY2 for stored queries that do wildcards, etc). That way any work that follows CAP that can deal w/useful stored queries wont be encumbered by a poor CAP design. (I feel Im overlooking something else here w/this change but Im tired so Ill let Andrea or Doug point it out.) > Will it change or extend VQUERY? Then we might need to check VQUERY > ABNF (I think > QUERY should be optional). > Will it introduce a new component? But all commands take VQUERY, so I > won't be able to send a SEARCH using VQUERY2... Hmm, there is a way to make this expansion savy but it requires a layer of wrapping OR some ABNF tweaking for the query format. That is, we select based on a VQUERY component that can have subcomponents that augment or supercede the query of the VQUERY. Alternately we could have a QUERYVERSION in the VQUERY to distinguish the kind of query it contains and make sure the ABNF allows for expansion (ie: wildcarding, etc)... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007CD82C85256C85_= Content-Type: text/html; charset="US-ASCII"
Andrea wrote on 11/19/2002 06:49:29 AM:
> Once again, I don't see the problem. If the CUA sends:
>
> BEGIN:VQUERY
> QUERY:SELECT VQUERY FROM VAGNEDA WHERE NAME = 'MAGIC01'
> ENV:VQUERY
>
> The CS replies:
>
> BEGIN:VQUERY
> QUERYID:MAGIC01
> END:VQUERY
>
> I don't see why you think it should be an error (although it would require
> an ABNF change) - the CS has the query so it sends what it has. It just
> happens to be unable to represent it in CAP-QL.

But the CS _DID_ represent it in CAP-QL.  It just happens that the CAP-QL is 'empty' and thus not really presentable to the CU.  

The VQUERY is just a name, no actions or anything that can be used to present or describe it to a CU.  As such this appears to be 'useless'; the knowledge that MAGIC01 is a canned non-CAP-QL query exists only at the CU level (above the CUA since there are no name spaces for VQUERYs to distinguish a CUAs MAGIC01 query from your CUA/CSs canned MAGIC01).

I would prefer some CS response to retrieving the non-CAP-QL encodable query like "505 - Server unable to encode the requested data" since this is also more useful going forwards in any expansion to CAP we design later on.

>                                                 Incidentally, that's the
> reason why a few months ago I proposed we added a way to specify the VQUERY
> is hardcoded in the CS and can't be represented in CAP-QL.
>
> BEGIN:VQUERY
> QUERYID:MAGIC01
> NATIVE:YES   (NATIVE is just an example, you can choose a better name)
> END:VQUERY
Kind of like the predefined VCARs but different in that its unencodable (currently) such that a CUA can retrieve it...  I think Id prefer that all data be encodable (even if its by adding new properties, components, etc) rather than taking a flag approach as a CUA may still want to be able to retrieve and present the MAGIC01 query to the CU; after all we dont have namespaces on them so we could get into a hairy mess when your CUA uses MAGIC01 to my CS and a totally different action happens that is expected...

> This would make clear to a CUA that it is looking at a valid VQUERY, but
> nothing is know about its implementation - so the CUA had better know what
> to do with it or leave it alone.
We would need some kind of name space for this to work.  See above.

> Also, do you really expect all CUAs to retrieve the VQUERY before calling
> it? Then what, do a string compare of the QUERY? It would be even less
> useful then.
As part of building a sync engine ALL components will have to be representable in a format that can be retrieved and pushed between 2 stores.  Otherwise it wont be able to sync fully and opening the door for VQUERYs only is just inserting a tiny wedge that allow for justification of other non-encodable representations to develop in the future.  Bad joss...

> I agree that CAP should allow storing any component. Of course, an actual CUA
> implementation should not expect to be able to store components the server
> doesn't list as supported in GET-CAPABILITY.
I concur w/the "expect" bit.  I would hope that a CS would try to store unknown components in some blobular way such that the CS (Calendar _Store_) can act as a true Store for newer data w/o having to actually grok it fully.  Nowhere does it say in CAP that a CS needs to be able to decypher the intent/meaning of a component; it only talks about how it should be represented for querys, etc.  This has an implicit "any blob will work" mentality but thats just my take on the text.

> > IMHO there should be no data put into the CS by ANY means (Administrative
> > or not) that cannot be retrieved and/or encoded using the CAP 1.0 or
> > updated iCalendar specs.  Otherwise it just becomes a recipe for disaster.
>
> I agree. It just happens to have no QUERY property, so what? It's still
> legal, so you can retrieve it.
If the 'native' querys are not encodable in a VQUERY then they cannot be returned in one obviously.  As such another means is necessary; a VQUERY2 or possible some other query mechanism and represenation.  In any case I think we are pretty much in agreement on this and the other issues.

> > response to the "SELECT VQUERY FROM VAGENDA ..." command.  I would not
> > expect a CUA to use a VQUERY that it cannot read from the CS, would you??
> > (I like to practice Save Hex...)
>
> That's a CUA choice. In controlled environments (the CUA knows it can
> trust the CS), it would be safe. Remember that I'm talking about hardcoded
> VQUERY, so no malicious CUA could change them.
If the CUA got back the 'empty' VQUERY you had at top then its not unlikely that a CU may see that there is nothing in the query and try to either delete it or modify it for their use.  The CUA _could_ prohibit this but again this gets back to the name space issue we have not addressed...

> Since I seem to be the only one to defend it, I have no problem with taking
> stored queries away and doing it properly in another draft. However, this
> requires thinking NOW about how the new draft will extend the current
> model.
The replacement design would be to expressly codify how a CS deals with new component types (ie: VQUERY2 for stored queries that do wildcards, etc).  That way any work that follows CAP that can deal w/useful stored queries wont be encumbered by a poor CAP design.  (I feel Im overlooking something else here w/this change but Im tired so Ill let Andrea or Doug point it out.)

> Will it change or extend VQUERY? Then we might need to check VQUERY
> ABNF (I think
> QUERY should be optional).
> Will it introduce a new component? But all commands take VQUERY, so I
> won't be able to send a SEARCH using VQUERY2...
Hmm, there is a way to make this expansion savy but it requires a layer of wrapping OR some ABNF tweaking for the query format.  That is, we select based on a VQUERY component that can have subcomponents that augment or supercede the query of the VQUERY.  Alternately we could have a QUERYVERSION in the VQUERY to distinguish the kind of query it contains and make sure the ABNF allows for expansion (ie: wildcarding, etc)...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 007CD82C85256C85_=-- From owner-ietf-calendar@mail.imc.org Wed Dec 4 18:19:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09769 for ; Wed, 4 Dec 2002 18:19:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB4NFOu04413 for ietf-calendar-bks; Wed, 4 Dec 2002 15:15:24 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4NFLg04409 for ; Wed, 4 Dec 2002 15:15:22 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gB4NFNC0024067 for ; Wed, 4 Dec 2002 15:15:23 -0800 Message-ID: <3DEE8C85.1050106@Royer.com> Date: Wed, 04 Dec 2002 16:15:17 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: Re: 10.4 IDENTIFY Command II] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090304090501000704030901" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090304090501000704030901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > > If you determined that a hacker was attacking your system, would > > you first inform them: > > > > > 1: Network failure > > > 2: CS crash/shutdown > > > 3: "Im a bad boy" > > > 4: "Im not allowed to be the CFO of the company" > > > 5: "Sorry C&S Team AA, you are still not allowed to assume > Bruces identity" > > > ... > > Hmm, Im impressed that you alone have developed the means to make > software clairvoyant and have imbued it with the ability to tell a > hacker from a legitimate user who is retrying something they think > should/will work. I have made no such claim. I claimed that if I detect a hacker - I am dropping the connection and I think that is good protocol practice. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms090304090501000704030901 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIwNDIzMTUxOFowIwYJKoZIhvcNAQkEMRYEFMQ+DTV8 Is2kKwm3QCQzCKwBe3J6MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQANFLGkGNhuK2rMdxtd yvRTRYeoxVZz3hlob1JBW9KcXRj86J6mbY3ecz7Hrg0077N9GE990q8HJMbKWmS8ziGCWZPq 61KNqbJMnn2fD5yuzvTtZyvq9CuN7XhMQ7oo5NiRw4m5dBCL5AXK18wxJ5wAvRwiE0MHamfr Gjqfhbx6IRIdyXdKU6VJMNxKfPTVvQTfu7zDhjBj3axhyT8FK2ZEkIXBQCUofPGiam/gZTO5 NI7swiUPVjB4sb/RGcwOoCpxyHHOUWX4McDAowZAkp0NB1izDXPh3w1ftkl2tQwmgfKaR+eR WissAwhmKDcyVbJqUgnsUOJ5GOm4O8FNfzJjAAAAAAAA --------------ms090304090501000704030901-- From owner-ietf-calendar@mail.imc.org Wed Dec 4 18:21:41 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09930 for ; Wed, 4 Dec 2002 18:21:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB4NEWB04396 for ietf-calendar-bks; Wed, 4 Dec 2002 15:14:32 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4NEUg04392 for ; Wed, 4 Dec 2002 15:14:30 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gB4NEVC0024049 for ; Wed, 4 Dec 2002 15:14:32 -0800 Message-ID: <3DEE8C52.1070607@Royer.com> Date: Wed, 04 Dec 2002 16:14:26 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: Re: CAP ABNF and external references] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000901000807080709000804" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms000901000807080709000804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > ...However your > new p-integer does allow for 0 which is still a non-useful value for > LATENCY. I agree the zero has no meaning - I'lll fix that. However if a initiator wishes to wait a very long time for the responder to complete, that is up to them. It does not stop the responder from responding earlier and it does not stop the responder from sending some kind of error before the timeout, both of which terminate the command. Your example of 24 hours seems excessive to me, but I would rather not limit it in the protocol as I feel the CUA and the CS implementations can decide. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms000901000807080709000804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIwNDIzMTQyNlowIwYJKoZIhvcNAQkEMRYEFO3mx9qa aP8NlgP+qRDcrzqpWN/1MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBQz8mNtO1dhLl5MzKn H3iYC/geZfX+WCNOJHwxYR7G9XRnKAFBCJxW6+pAcvoJidhrMBsPEPc/3Y2lXj24hVblwa69 dmoTOVsxQ6yYiQRoDam3sd38YRJ9nimhhbJdtVrNxWDRnsJn+voQeNHTbNHg3C8FCYkEQjyP vZl7pY0F/PqEoQBlMcs7KQEljEYYNyxBF6uVXpS+jLBnBKvFwbkzK2Od0qpNOD6nt0c38HIx GbF5w6JvEfvhbip/hzs80ZmSFm5jXDLijCw6kWMo3G/dMJZPuuYT44cGS/n64sj2R9etDFzM 804VuH1HmfqdXU532usmAoh3Dmq40bjnVAWpAAAAAAAA --------------ms000901000807080709000804-- From owner-ietf-calendar@mail.imc.org Thu Dec 5 04:33:02 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05337 for ; Thu, 5 Dec 2002 04:33:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB59NOd18616 for ietf-calendar-bks; Thu, 5 Dec 2002 01:23:24 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB59NLg18603 for ; Thu, 5 Dec 2002 01:23:21 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 6E80A155AC; Thu, 5 Dec 2002 10:23:15 +0100 (CET) Date: Thu, 5 Dec 2002 10:23:14 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: What good are stored VQUERYs? Message-ID: <20021205092314.GB17308@inet.it> References: <20021119114928.GM96286@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I don't have much time at hands right now, so I'll only briefly reply to parts of your email... On Wed, Dec 04, 2002 at 05:43:03PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > > This would make clear to a CUA that it is looking at a valid VQUERY, but > > nothing is know about its implementation - so the CUA had better know > what > > to do with it or leave it alone. > > We would need some kind of name space for this to work. See above. Well, we have something like that; at least, we had a proposal which several people including Doug agreed to. See <1028739969.18782.107.camel@c-1241.in.steltor.com> from Patrice Lapierre and followups. I have no idea why this wasn't integrated in the draft. The idea is to add a TARGET property when operating with stored queries, to indicate where you want to store or fetch the query from. Don't you think this would address your objections? > I concur w/the "expect" bit. I would hope that a CS would try to store > unknown components in some blobular way such that the CS (Calendar > _Store_) can act as a true Store for newer data w/o having to actually > grok it fully. Nowhere does it say in CAP that a CS needs to be able to > decypher the intent/meaning of a component; it only talks about how it > should be represented for querys, etc. This has an implicit "any blob > will work" mentality but thats just my take on the text. I concur this is a desirable behavior, and one which would make extensibility much much easier. However, if this is the expected behavior, there should be something to that effect in the draft. I see nothing like that currently. > > That's a CUA choice. In controlled environments (the CUA knows it can > > trust the CS), it would be safe. Remember that I'm talking about > hardcoded > > VQUERY, so no malicious CUA could change them. > > If the CUA got back the 'empty' VQUERY you had at top then its not > unlikely that a CU may see that there is nothing in the query and try to > either delete it or modify it for their use. The CUA _could_ prohibit > this but again this gets back to the name space issue we have not > addressed... Personally, if my CS and my CUA both know that cap://cap.example.com/inet.it-stored-queries, then I'd write my CUA so that it doesn't show the CU anything about queries stored there. IMO this is just a form of an RPC so it's internal to the CUA and CS couple. This is useful if you have exclusive control of both; or if the stored queries are standardized. > The replacement design would be to expressly codify how a CS deals with > new component types (ie: VQUERY2 for stored queries that do wildcards, [...] > Hmm, there is a way to make this expansion savy but it requires a layer of > wrapping OR some ABNF tweaking for the query format. That is, we select I need to think more about this; I'm too busy ATM. Maybe we should find a way to discuss this more in depth between a few of us in a more interative way... Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu Dec 5 06:33:42 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07993 for ; Thu, 5 Dec 2002 06:33:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB5BOgP03630 for ietf-calendar-bks; Thu, 5 Dec 2002 03:24:42 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5BOeg03626 for ; Thu, 5 Dec 2002 03:24:41 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 30E44155AC; Thu, 5 Dec 2002 12:24:36 +0100 (CET) Date: Thu, 5 Dec 2002 12:24:36 +0100 From: Andrea Campi To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP ABNF and external references] Message-ID: <20021205112436.GE17308@inet.it> References: <3DEE8C52.1070607@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DEE8C52.1070607@Royer.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Wed, Dec 04, 2002 at 04:14:26PM -0700, Doug Royer wrote: > the responder to complete, that is up to them. It > does not stop the responder from responding earlier > and it does not stop the responder from sending some kind > of error before the timeout, both of which terminate > the command. I think we should state this explicitely. That is, the responder may respond with a timeout error of sort even before the initiator specified expires. Bye, andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu Dec 5 13:29:04 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22631 for ; Thu, 5 Dec 2002 13:29:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB5IL9H08053 for ietf-calendar-bks; Thu, 5 Dec 2002 10:21:09 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5IL6g08049 for ; Thu, 5 Dec 2002 10:21:06 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gB5IL7C0000632 for ; Thu, 5 Dec 2002 10:21:07 -0800 Message-ID: <3DEF990D.4080401@Royer.com> Date: Thu, 05 Dec 2002 11:21:01 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP ABNF and external references] References: <3DEE8C52.1070607@Royer.com> <20021205112436.GE17308@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040704000802030109020203" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms040704000802030109020203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andrea Campi wrote: > On Wed, Dec 04, 2002 at 04:14:26PM -0700, Doug Royer wrote: > >>the responder to complete, that is up to them. It >>does not stop the responder from responding earlier >>and it does not stop the responder from sending some kind >>of error before the timeout, both of which terminate >>the command. > > > I think we should state this explicitely. That is, the responder > may respond with a timeout error of sort even before the initiator > specified expires. Sorry - I did not mean to say that. I meant that the responder may reply with an error. However I guess any valid error would do, including 'server temporally unavailable' or something. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms040704000802030109020203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIwNTE4MjEwMlowIwYJKoZIhvcNAQkEMRYEFGR5wb8w bzwRLgQxO/w105w4dvKhMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAaCKotcgN6en6ushM/ inhkXqDsuLFS8xMBDlHkyf0kSIspmnv/+HxWAU/pMlTAkG8EJsJutGJBkyMmvJ0i83mHl8ze LnBGi+QyG3yxmMShycu4epJ3q7NWY5cSxAJuUuuIrbpcPxlEBnprT1GiPQ0LHskpXuqmTlwu 8XnfJQtfAon/ilte4prEgkNRypWisD2Tz3RsRnn/18JyjUwLvHo0LDIPF9TI5PcatbS3nN3M XSLAnxsB4JcdiVzP9atjSZjXg4RUpiPy7BdbP1h36w6TSU9gnKu148fUbdR1Uk1B3GAZJoPG mwQbR6I+4d6kImqwfbdJmPhDDNrjuxtqQ1ihAAAAAAAA --------------ms040704000802030109020203-- From owner-ietf-calendar@mail.imc.org Thu Dec 5 13:32:39 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22720 for ; Thu, 5 Dec 2002 13:32:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB5IPOj08387 for ietf-calendar-bks; Thu, 5 Dec 2002 10:25:24 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5IPMg08381 for ; Thu, 5 Dec 2002 10:25:22 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gB5IPMC0000668 for ; Thu, 5 Dec 2002 10:25:23 -0800 Message-ID: <3DEF9A0D.1060609@Royer.com> Date: Thu, 05 Dec 2002 11:25:17 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: What good are stored VQUERYs? References: <20021119114928.GM96286@inet.it> <20021205092314.GB17308@inet.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010902020406060308070309" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010902020406060308070309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andrea Campi wrote: > > Well, we have something like that; at least, we had a proposal which > several people including Doug agreed to. See > <1028739969.18782.107.camel@c-1241.in.steltor.com> from Patrice Lapierre > and followups. I have no idea why this > wasn't integrated in the draft. In the ABNF: ; 'queryid' is OPTIONAL but MUST NOT occur ; more than once. If the "TARGET" property ; is supplied then the "QUERYID" property ; MUST BE supplied. ; and later below the ABNF: For a search, if the "TARGET" property is supplied in a "VQUERY" component, then the CS is to search for the query in the calid supplied by the "TARGET" property value. For a create the "TARGET" property MUST NOT be supplied as the destination container is already supplied in the "TARGET" property of the "VCALENDAR" component. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010902020406060308070309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIwNTE4MjUxN1owIwYJKoZIhvcNAQkEMRYEFEz5yVyI 9yY9QQtpYAeK7LvfDFpMMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAPMmTKkM3AzRon3+t6 qDrfjAk95SJBJyPFJHtLKCxUkkCGrTTA9OjoeckufHOOiLKtUU/4h5wI3qqVGQJNhblxaBum 6veBuHcvD4yR52M3bmcDC+g8msPKytyHpw5aUxBV79MOe7L3vbTElitobKnjiW2VrarevMR8 /hdi/ih4ID6BtbJQs9wyTe+7FSc4ZiQnCCIQLJZxUJPrycInlLRGlwjwP2rsUth5eNPCOtCU AVY8gbr+hG9pJ2RZrq6FyTDb5uI/vOZo2p4YSMvkISC7lHPn47GRgacsyGQGtXPNDTsS/3t+ L7+KW1J5N2hwePvefV/2opb6x+rsi5fNcbQ1AAAAAAAA --------------ms010902020406060308070309-- From owner-ietf-calendar@mail.imc.org Fri Dec 6 04:06:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29526 for ; Fri, 6 Dec 2002 04:06:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB68qmc23063 for ietf-calendar-bks; Fri, 6 Dec 2002 00:52:48 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB68qkg23059 for ; Fri, 6 Dec 2002 00:52:46 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id 1DC12155AC; Fri, 6 Dec 2002 09:52:41 +0100 (CET) Date: Fri, 6 Dec 2002 09:52:40 +0100 From: Andrea Campi To: ietf-calendar@imc.org Subject: Re: What good are stored VQUERYs? Message-ID: <20021206085240.GA25273@inet.it> References: <20021119114928.GM96286@inet.it> <20021205092314.GB17308@inet.it> <3DEF9A0D.1060609@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DEF9A0D.1060609@Royer.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Dec 05, 2002 at 11:25:17AM -0700, Doug Royer wrote: > and later below the ABNF: > > For a search, if the "TARGET" property is supplied in a "VQUERY" > component, then the CS is to search for the query in the calid > supplied by the "TARGET" property value. > Sorry Doug, I must have overlooked it. Thanks for pointing out. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Fri Dec 6 04:07:58 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29586 for ; Fri, 6 Dec 2002 04:07:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB68wq623867 for ietf-calendar-bks; Fri, 6 Dec 2002 00:58:52 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB68wlg23863 for ; Fri, 6 Dec 2002 00:58:48 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id D8B39155AC; Fri, 6 Dec 2002 09:58:44 +0100 (CET) Date: Fri, 6 Dec 2002 09:58:44 +0100 From: Andrea Campi To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP ABNF and external references] Message-ID: <20021206085844.GB25273@inet.it> References: <3DEE8C52.1070607@Royer.com> <20021205112436.GE17308@inet.it> <3DEF990D.4080401@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DEF990D.4080401@Royer.com> Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Dec 05, 2002 at 11:21:01AM -0700, Doug Royer wrote: > >I think we should state this explicitely. That is, the responder > >may respond with a timeout error of sort even before the initiator > >specified expires. > > Sorry - I did not mean to say that. I meant that the responder > may reply with an error. However I guess any valid error would do, > including 'server temporally unavailable' or something. > Regardless, we seem to be in agreement, right? Note that I was referring more to something like "server has run out of resources", or even "processing time quota exceeded". It's a policy decision on the server side, and the CUA won't care, as long as the error code is right. Ideally we should have error code(s) that indicate this is not a permanent error, but you might need to simplify your request. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Fri Dec 6 12:20:17 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14628 for ; Fri, 6 Dec 2002 12:20:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB6H8EQ05461 for ietf-calendar-bks; Fri, 6 Dec 2002 09:08:14 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6H8Bg05451 for ; Fri, 6 Dec 2002 09:08:11 -0800 (PST) In-Reply-To: <3DEE8C85.1050106@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: 10.4 IDENTIFY Command II] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 6 Dec 2002 12:04:57 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 12/06/2002 12:08:00 PM, Serialize complete at 12/06/2002 12:08:00 PM Content-Type: multipart/alternative; boundary="=_alternative 005DE5D185256C87_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005DE5D185256C87_= Content-Type: text/plain; charset="US-ASCII" Doug responded on 12/04/2002 06:15:17 PM: > > > If you determined that a hacker was attacking your system, would > > > you first inform them: > > > > > > > 1: Network failure > > > > 2: CS crash/shutdown > > > > 3: "Im a bad boy" > > > > 4: "Im not allowed to be the CFO of the company" > > > > 5: "Sorry C&S Team AA, you are still not allowed to assume > > Bruces identity" > > > > ... > > > > Hmm, Im impressed that you alone have developed the means to make > > software clairvoyant and have imbued it with the ability to tell a > > hacker from a legitimate user who is retrying something they think > > should/will work. > > I have made no such claim. I claimed that if I detect > a hacker - I am dropping the connection and I think > that is good protocol practice. Before this determination can be made there must have been at least a couple failed attempts. _THESE_ should have some kind of response on them that indicate the cause for the failure (see numbered cases above). As I originally stated back on 18-Nov: "The CS should _at_least_ send back some info before slamming the entire BEEP session. Otherwise the CUA has NO way to determine why the connection to the CS was lost" The current description and draft make no mention of this and I think that it should. _BEFORE_ the CS gets to the point of making the determination of a possible security breach the CS should be sending back informative failure responses for the CUA to use, present to the CU or just plain log! I for one would expect the CS to be consistant and just send back a (3) response _before_ it just dropped the connection and punted the CUA but perhaps thats just me. After all doing that would be consistant w/non-punting cases AND its not giving any extra info to any potential hacker... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005DE5D185256C87_= Content-Type: text/html; charset="US-ASCII"
Doug responded on 12/04/2002 06:15:17 PM:
>  >  > If you determined that a hacker was attacking your system, would
>  >  > you first inform them:
>  >  >
>  >  >    > 1: Network failure
>  >  >    > 2: CS crash/shutdown
>  >  >    > 3: "Im a bad boy"
>  >  >    > 4: "Im not allowed to be the CFO of the company"
>  >  >    > 5: "Sorry C&S Team AA, you are still not allowed to assume
>  > Bruces identity"
>  >  >    > ...
>  >
>  > Hmm, Im impressed that you alone have developed the means to make
>  > software clairvoyant and have imbued it with the ability to tell a
>  > hacker from a legitimate user who is retrying something they think
>  > should/will work.
>
> I have made no such claim. I claimed that if I detect
> a hacker - I am dropping the connection and I think
> that is good protocol practice.
Before this determination can be made there must have been at least a couple failed attempts.  _THESE_ should have some kind of response on them that indicate the cause for the failure (see numbered cases above).  

As I originally stated back on 18-Nov: "The CS should _at_least_ send back some info before slamming the entire BEEP session.  Otherwise the CUA has NO way to determine why the connection to the CS was lost"  The current description and draft make no mention of this and I think that it should.  _BEFORE_ the CS gets to the point of making the determination of a possible security breach the CS should be sending back informative failure responses for the CUA to use, present to the CU or just plain log!

I for one would expect the CS to be consistant and just send back a (3) response _before_ it just dropped the connection and punted the CUA but perhaps thats just me.  After all doing that would be consistant w/non-punting cases AND its not giving any extra info to any potential hacker...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 005DE5D185256C87_=-- From owner-ietf-calendar@mail.imc.org Fri Dec 6 12:28:17 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15059 for ; Fri, 6 Dec 2002 12:28:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB6HJBx07412 for ietf-calendar-bks; Fri, 6 Dec 2002 09:19:11 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6HJ8g07408 for ; Fri, 6 Dec 2002 09:19:09 -0800 (PST) To: ietf-calendar@imc.org Subject: Expiring of LATENCY MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 6 Dec 2002 12:18:56 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 12/06/2002 12:18:56 PM, Serialize complete at 12/06/2002 12:18:56 PM Content-Type: multipart/alternative; boundary="=_alternative 005F2D6785256C87_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 005F2D6785256C87_= Content-Type: text/plain; charset="US-ASCII" In 09-submitted I found: If a CS can both start sending the reply to a command and guarantee that all of the results can be sent from a command (short of something like network or power falure), prior to the "LATENCY" timeout value, then the "LETENCY" time has not expired. I think this is a bit misleading/vague/useless as I doubt the CS has the ability to guarantee that it can return all the data prior to the timeout value occuring. After all, if the CS can find the 500 entires on my calendar for this week in under 5 seconds (I have a fast backend store), the CS may not be able to tell if it can actually encode and send them all before 5 seconds have elapsed. Should the CS timeout in the middle of sending data or before it begins because it knows it cant encode and send such a large blob of data in the alloted time?? Should the CS send what it can even though it knows it wont finish and then take the ACTION required? Does it actually matter if the LATENCY time expired before the actual time _does_ pass?? That is, my CS determines it will take 7 seconds to encode and shove out the requested data but LATENCY=5 was used. So should the CS consider that LATENCY expired and if so, so what?? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 005F2D6785256C87_= Content-Type: text/html; charset="US-ASCII"
In 09-submitted I found:

   If a CS can both start sending the reply to a command and guarantee
  that all of the results can be sent from a command (short of
  something like network or power falure), prior to the "LATENCY"
  timeout value, then the "LETENCY" time has not expired.

I think this is a bit misleading/vague/useless as I doubt the CS has the ability to guarantee that it can return all the data prior to the timeout value occuring.  After all, if the CS can find the 500 entires on my calendar for this week in under 5 seconds (I have a fast backend store), the CS may not be able to tell if it can actually encode and send them all before 5 seconds have elapsed.

Should the CS timeout in the middle of sending data or before it begins because it knows it cant encode and send such a large blob of data in the alloted time??

Should the CS send what it can even though it knows it wont finish and then take the ACTION required?

Does it actually matter if the LATENCY time expired before the actual time _does_ pass??  That is, my CS determines it will take 7 seconds to encode and shove out the requested data but LATENCY=5 was used.  So should the CS consider that LATENCY expired and if so, so what??

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 005F2D6785256C87_=-- From owner-ietf-calendar@mail.imc.org Fri Dec 6 12:39:33 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15662 for ; Fri, 6 Dec 2002 12:39:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB6HTaK08060 for ietf-calendar-bks; Fri, 6 Dec 2002 09:29:36 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6HTYg08054 for ; Fri, 6 Dec 2002 09:29:34 -0800 (PST) In-Reply-To: <3DEE8C52.1070607@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: CAP ABNF and external references] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 6 Dec 2002 12:29:32 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 12/06/2002 12:29:21 PM, Serialize complete at 12/06/2002 12:29:21 PM Content-Type: multipart/alternative; boundary="=_alternative 006025F685256C87_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006025F685256C87_= Content-Type: text/plain; charset="US-ASCII" Doug noted on 12/04/2002 06:14:26 PM: > > ...However your > > new p-integer does allow for 0 which is still a non-useful value for > > LATENCY. > > I agree the zero has no meaning - I'lll fix that. So are you taking the position that NO latency-param means "Never times out"?? Im on the fence but the more I think about it the more Im inclined to mandate that latency-param MUST be specified and that "0" mean "Never times out". See previous post in this thread for more info on this... In any case CAP 1.0 09-submitted is unclear as to what it means when no latency-param is specified and that needs to be rectified before it can pass WG last call. > However if a initiator wishes to wait a very long time for > the responder to complete, that is up to them. Agreed. However I do think that ~68 years is a bit excessive no matter what your definition of "very long time" is... > It > does not stop the responder from responding earlier > and it does not stop the responder from sending some kind > of error before the timeout, both of which terminate > the command. This case is not described in 09-submitted and I think it needs to be before this confusion can be considered resolved. Section 10.1.1 Bounded Latency covers many permuations but there is no talk of returning partial results. This needs to be covered in text in 10.1.1 where latency is covered. > Your example of 24 hours seems excessive to me, but > I would rather not limit it in the protocol as I feel > the CUA and the CS implementations can decide. There already is a limit if you use integer (or a modified integer) from 2445 which already defines "The valid range for "integer" is -2147483648 to 2147483647.". Even if we simplify this to 1..2147483647 thats a damn long time for any single command to complete. In the interest of KISS I think we should shorten it to something more reasonable for a single CAP command since we are already making changes and not adopting 2445's integer as is. But thats just my preference, your mileage may vary. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006025F685256C87_= Content-Type: text/html; charset="US-ASCII"
Doug noted on 12/04/2002 06:14:26 PM:
>  > ...However your
>  > new p-integer does allow for 0 which is still a non-useful value for
>  > LATENCY.
>
> I agree the zero has no meaning - I'lll fix that.
So are you taking the position that NO latency-param means "Never times out"??

Im on the fence but the more I think about it the more Im inclined to mandate that latency-param MUST be specified and that "0" mean "Never times out".  See previous post in this thread for more info on this...

In any case CAP 1.0 09-submitted is unclear as to what it means when no latency-param is specified and that needs to be rectified before it can pass WG last call.

> However if a initiator wishes to wait a very long time for
> the responder to complete, that is up to them.

Agreed.  However I do think that ~68 years is a bit excessive no matter what your definition of "very long time" is...

>                                                 It
> does not stop the responder from responding earlier
> and it does not stop the responder from sending some kind
> of error before the timeout, both of which terminate
> the command.
This case is not described in 09-submitted and I think it needs to be before this confusion can be considered resolved.  Section 10.1.1 Bounded Latency covers many permuations but there is no talk of returning partial results.  This needs to be covered in text in 10.1.1 where latency is covered.

> Your example of 24 hours seems excessive to me, but
> I would rather not limit it in the protocol as I feel
> the CUA and the CS implementations can decide.
There already is a limit if you use integer (or a modified integer) from 2445 which already defines "The valid range for "integer" is -2147483648 to 2147483647.".  Even if we simplify this to 1..2147483647 thats a damn long time for any single command to complete.  In the interest of KISS I think we should shorten it to something more reasonable for a single CAP command since we are already making changes and not adopting 2445's integer as is.  But thats just my preference, your mileage may vary.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 006025F685256C87_=-- From owner-ietf-calendar@mail.imc.org Fri Dec 6 13:05:01 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16950 for ; Fri, 6 Dec 2002 13:04:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB6HuPf09365 for ietf-calendar-bks; Fri, 6 Dec 2002 09:56:25 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6HuMg09359 for ; Fri, 6 Dec 2002 09:56:22 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gB6HuMC0011440 for ; Fri, 6 Dec 2002 09:56:22 -0800 Message-ID: <3DF0E4C0.9020800@Royer.com> Date: Fri, 06 Dec 2002 10:56:16 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: Expiring of LATENCY References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050601080300040204070209" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms050601080300040204070209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit How about: If a CS can start sending the reply to a command prior to the "LATENCY" timeout value, then the "LATENCY" time has not expired. Bruce_Kahn@notesdev.ibm.com wrote: > > In 09-submitted I found: > > If a CS can both start sending the reply to a command and guarantee > that all of the results can be sent from a command (short of > something like network or power falure), prior to the "LATENCY" > timeout value, then the "LETENCY" time has not expired. > > I think this is a bit misleading/vague/useless as I doubt the CS has the > ability to guarantee that it can return all the data prior to the > timeout value occuring. After all, if the CS can find the 500 entires > on my calendar for this week in under 5 seconds (I have a fast backend > store), the CS may not be able to tell if it can actually encode and > send them all before 5 seconds have elapsed. > > Should the CS timeout in the middle of sending data or before it begins > because it knows it cant encode and send such a large blob of data in > the alloted time?? > > Should the CS send what it can even though it knows it wont finish and > then take the ACTION required? > > Does it actually matter if the LATENCY time expired before the actual > time _does_ pass?? That is, my CS determines it will take 7 seconds to > encode and shove out the requested data but LATENCY=5 was used. So > should the CS consider that LATENCY expired and if so, so what?? > > Bruce > =========================================================================== > Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com > Messaging & Collaboration Phone: 978.399.6496 > IBM Software Group FAX: and nothing but the FAX... > Standard disclaimers apply, even where prohibited by law... -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms050601080300040204070209 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIwNjE3NTYxNlowIwYJKoZIhvcNAQkEMRYEFAyIJOLx 2QAco1KQed6UCbGXKPmAMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQAqWpl2B9nhSetv2YKN SD7zRtw72M4Q8NYb6VTnxR26wOGDg6wF/vadJxRV6mLDqJC6gBlURJ/5D/GmYPx7oH9l2Onv WlAaxiNCzERSBVE4iQcOE11r1RJRx83bA9EzlWzFjkJngvyiz3AQ9juGU++YuiwrY8ueWb+4 V+CrPIFL0Oq3FxWpIJSSzMplb22gTEs8XbKnWzEtK31hn7IIut19vd1yI96uOPOcvFJAnDMl SWfMK4UcBFQm7UGQfLccqJ5fbsrDRIZZLil+0yTyTB656+0wy9ru7i4RqhfZALljCsT+TNJE ZlbusndfBog3fiNvRLtyoTIbDpY+N5VYh02VAAAAAAAA --------------ms050601080300040204070209-- From owner-ietf-calendar@mail.imc.org Fri Dec 6 13:36:10 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18496 for ; Fri, 6 Dec 2002 13:36:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB6IGUt11691 for ietf-calendar-bks; Fri, 6 Dec 2002 10:16:30 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6IGSg11681 for ; Fri, 6 Dec 2002 10:16:28 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gB6IGSC0011594 for ; Fri, 6 Dec 2002 10:16:28 -0800 Message-ID: <3DF0E977.3060802@Royer.com> Date: Fri, 06 Dec 2002 11:16:23 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: [Fwd: Re: [Fwd: Re: CAP ABNF and external references]] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030104080806050601000606" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030104080806050601000606 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug noted on 12/04/2002 06:14:26 PM: > > > ...However your > > > new p-integer does allow for 0 which is still a non-useful value for > > > LATENCY. > > > > I agree the zero has no meaning - I'lll fix that. > > So are you taking the position that NO latency-param means "Never times > out"?? No. I am saying I agree that zero has no meaning - I'll fix that. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030104080806050601000606 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIwNjE4MTYyM1owIwYJKoZIhvcNAQkEMRYEFCbdh5Vy CI/8bdo72kRrdBHkfNkfMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQCrruATNIbVYmYxHA8c IHiVIgsjqCg9wfE+hhIthqJDeWImkgS+/jAa2BjxUDVVRKd+AzwOfCwPmtB8PzkswBG9BYkb swqG16DccDn+VrdvvnJ5HbOrNKnx+VrVDpoaGShbWh27TJGSoh09OpVEr574d1+l4OIINTJi 5SikXnDdE8/wgZhzso9jCIXNzzUxiQqC39L8MI/oyNHdYduPURLb7nyE3aHNyqhILTSnWdZq AqEfEvclZWtyDsrZnVsy5IcVJNojTDjMvMOGXPjIjdELB8nms56tT1RApT/BrTO+hjG+JmAE JLdbiPBymcpQl/kzriSwL2DiWquSJVh8lWdfAAAAAAAA --------------ms030104080806050601000606-- From owner-ietf-calendar@mail.imc.org Fri Dec 6 13:40:27 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18692 for ; Fri, 6 Dec 2002 13:40:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB6IHkU11895 for ietf-calendar-bks; Fri, 6 Dec 2002 10:17:46 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6IHhg11886 for ; Fri, 6 Dec 2002 10:17:44 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id D37E5155AC; Fri, 6 Dec 2002 19:17:40 +0100 (CET) Date: Fri, 6 Dec 2002 19:17:40 +0100 From: Andrea Campi To: Bruce_Kahn@notesdev.ibm.com Cc: ietf-calendar@imc.org Subject: Re: Expiring of LATENCY Message-ID: <20021206181740.GP25273@inet.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, Dec 06, 2002 at 12:18:56PM -0500, Bruce_Kahn@notesdev.ibm.com wrote: > I think this is a bit misleading/vague/useless as I doubt the CS has the > ability to guarantee that it can return all the data prior to the timeout > value occuring. After all, if the CS can find the 500 entires on my > calendar for this week in under 5 seconds (I have a fast backend store), > the CS may not be able to tell if it can actually encode and send them all > before 5 seconds have elapsed. I share your same doubts about the ambiguity. I'd say latency should mean the latency, not the delay: that is, the time until the first data is received, not the last. This IMHO is what matters most: you want your CUA to be able to put an upper to the amount of time it's willing to sit there doing nothing. When it starts getting data, no matter if it's able to act upon that or not, the CUA will be able to at least show the current speed or something like that; and the CU will be able to decide by herself if she wants to continue or cancel. Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Fri Dec 6 13:58:39 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19549 for ; Fri, 6 Dec 2002 13:58:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB6ImHh15986 for ietf-calendar-bks; Fri, 6 Dec 2002 10:48:17 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6Im4g15974 for ; Fri, 6 Dec 2002 10:48:15 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gB6Im5C0011861 for ; Fri, 6 Dec 2002 10:48:06 -0800 Message-ID: <3DF0F0E0.60807@Royer.com> Date: Fri, 06 Dec 2002 11:48:00 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP ABNF and external references Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > In any case CAP 1.0 09-submitted is unclear as to what it means when no > latency-param is specified and that needs to be rectified before it can > pass WG last call. I'll add: If LATENCY is not specified, then the initiator is indicating that any timeouts are up to the responder. > > It > > does not stop the responder from responding earlier > > and it does not stop the responder from sending some kind > > of error before the timeout, both of which terminate > > the command. > > This case is not described in 09-submitted and I think it needs to be > before this confusion can be considered resolved. Section 10.1.1 > Bounded Latency covers many permuations but there is no talk of > returning partial results. This needs to be covered in text in 10.1.1 > where latency is covered. Sure it is: If a CS can both start sending the reply to a command and guarantee that all of the results can be sent from a command (short of something like network or power falure), prior to the "LATENCY" timeout value, then the "LETENCY" time has not expired. (the above text being re-writted see separate e-mail on this list) Simply send a reply. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards From owner-ietf-calendar@mail.imc.org Fri Dec 6 16:10:26 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24500 for ; Fri, 6 Dec 2002 16:10:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB6Kxpc28510 for ietf-calendar-bks; Fri, 6 Dec 2002 12:59:51 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6Kxjg28493 for ; Fri, 6 Dec 2002 12:59:47 -0800 (PST) In-Reply-To: <3DF0E4C0.9020800@Royer.com> To: ietf-calendar@imc.org Subject: Re: Expiring of LATENCY MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 6 Dec 2002 15:52:36 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 12/06/2002 03:59:44 PM, Serialize complete at 12/06/2002 03:59:44 PM Content-Type: multipart/alternative; boundary="=_alternative 0072BD3E85256C87_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0072BD3E85256C87_= Content-Type: text/plain; charset="US-ASCII" Doug suggested on 12/06/2002 12:56:16 PM: > How about: > > If a CS can start sending the reply to a command > prior to the "LATENCY" timeout value, then the "LATENCY" > time has not expired. That would be better if it were single sided but bounded latency can be either way. As such how about: If a reply to a command can be sent (or begun to be sent) prior to the "LATENCY" timeout value, then the "LATENCY" time has not expired. This will cover both the CS and the CUA as the command sender as well as the case where some reply can be at least begun to be sent if not entirely completed. Polish up the phrasing as you desire... Related editorial nit, in paragraph above the corrected text above is: If the maximum latency time ... you should remove the phrase 'maximum' as we dont have a minimum value do we??... The latency time is the maximum time the command processor should delay but including 'maximum' in the text makes it sound like maxver/minver of sort. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0072BD3E85256C87_= Content-Type: text/html; charset="US-ASCII"
Doug suggested on 12/06/2002 12:56:16 PM:
> How about:
>
>    If a CS can start sending the reply to a command
>    prior to the "LATENCY" timeout value, then the "LATENCY"
>    time has not expired.
That would be better if it were single sided but bounded latency can be either way.  As such how about:

    If a reply to a command can be sent (or begun to be sent)
    prior to the "LATENCY" timeout value, then the "LATENCY"
    time has not expired.
This will cover both the CS and the CUA as the command sender as well as the case where some reply can be at least begun to be sent if not entirely completed.  Polish up the phrasing as you desire...

Related editorial nit, in paragraph above the corrected text above is:

    If the maximum latency time ...

you should remove the phrase 'maximum' as we dont have a minimum value do we??...  The latency time is the maximum time the command processor should delay but including 'maximum' in the text makes it sound like maxver/minver of sort.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 0072BD3E85256C87_=-- From owner-ietf-calendar@mail.imc.org Fri Dec 6 16:50:06 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26216 for ; Fri, 6 Dec 2002 16:50:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB6LcBN03055 for ietf-calendar-bks; Fri, 6 Dec 2002 13:38:11 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6Lc5g03051 for ; Fri, 6 Dec 2002 13:38:06 -0800 (PST) In-Reply-To: <3DEF9A0D.1060609@Royer.com> To: ietf-calendar@imc.org Subject: Re: What good are stored VQUERYs? MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 6 Dec 2002 16:36:10 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 12/06/2002 04:38:00 PM, Serialize complete at 12/06/2002 04:38:00 PM Content-Type: multipart/alternative; boundary="=_alternative 0076BA7785256C87_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0076BA7785256C87_= Content-Type: text/plain; charset="US-ASCII" Doug noted on 12/05/2002 01:25:17 PM: > For a search, if the "TARGET" property is supplied in a "VQUERY" > component, then the CS is to search for the query in the calid > supplied by the "TARGET" property value. Ok, I may be a bit rusty on the drafts finer details but if the normal structure of the CAP command is basically: BEGIN:VCALENDAR PROID:/HandCraftedWithLove VERSION:2.0 CMD: TARGET:RELCALID01 BEGIN:VQUERY ... END:VQUERY END:VCALENDAR where the inner BEGIN/END varies by whats being created in the TARGETs then wouldn't a SEARCH just need the TARGET in the 'outer' layer instead of having one inside the VQUERY. That is, why is: BEGIN:VCALENDAR PROID:/HandCraftedWithLove VERSION:2.0 CMD:SEARCH TARGET:RELCALID01 BEGIN:VQUERY QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT WHERE DTEND >= '19990310T080000Z' AND DTSTART <= '19990310T190000Z' AND STATE() = 'BOOKED' END:VQUERY END:VCALENDAR good enough to get say, "objects on March 10,1999 between 080000Z and 190000Z" (no TARGETs inside the VQUERY) but to use a 'named query' I would have to use: BEGIN:VCALENDAR PROID:/HandCraftedWithLove VERSION:2.0 CMD:CREATE TARGET:RELCALID01 BEGIN:VQUERY QUERYID:VOODOO1 TARGET:RELCALID01 END:VQUERY END:VCALENDAR if I stored the QUERY? Why isnt the TARGET from the VCALENDAR sufficient to find the VQUERY in RELCALID01? There can only be 1 QUERYID:VOODOO1 in RELCALID01 right?? What am I missing here? Would the TARGET in the VCALENDAR ever be different from that of the VQUERY?? Hmm, are you trying to use a stored VQUERY from a someone elses calendar, is that it?? > For a create the "TARGET" property MUST NOT be supplied as the > destination container is already supplied in the "TARGET" property of > the "VCALENDAR" component. This I grok and agree with... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0076BA7785256C87_= Content-Type: text/html; charset="US-ASCII"
Doug noted on 12/05/2002 01:25:17 PM:
>     For a search, if the "TARGET" property is supplied in a "VQUERY"
>     component, then the CS is to search for the query in the calid
>     supplied by the "TARGET" property value.
Ok, I may be a bit rusty on the drafts finer details but if the normal structure of the CAP command is basically:

BEGIN:VCALENDAR
PROID:/HandCraftedWithLove
VERSION:2.0
CMD:<SOME_COMMAND>
TARGET:RELCALID01
BEGIN:VQUERY
...
END:VQUERY
END:VCALENDAR

where the inner BEGIN/END varies by whats being created in the TARGETs then wouldn't a SEARCH just need the TARGET in the 'outer' layer instead of having one inside the VQUERY.  That is, why is:

BEGIN:VCALENDAR
PROID:/HandCraftedWithLove
VERSION:2.0
CMD:SEARCH
TARGET:RELCALID01
BEGIN:VQUERY
QUERY:SELECT DTSTART,DTEND,SUMMARY,UID
FROM VEVENT
WHERE DTEND >= '19990310T080000Z'
AND DTSTART <= '19990310T190000Z'
AND STATE() = 'BOOKED'
END:VQUERY
END:VCALENDAR

good enough to get say, "objects on March 10,1999 between 080000Z and 190000Z" (no TARGETs inside the VQUERY) but to use a 'named query' I would have to use:

BEGIN:VCALENDAR
PROID:/HandCraftedWithLove
VERSION:2.0
CMD:CREATE
TARGET:RELCALID01
BEGIN:VQUERY
QUERYID:VOODOO1
TARGET:RELCALID01
END:VQUERY
END:VCALENDAR

if I stored the QUERY?  Why isnt the TARGET from the VCALENDAR sufficient to find the VQUERY in RELCALID01?  There can only be 1 QUERYID:VOODOO1 in RELCALID01 right??  What am I missing here?  Would the TARGET in the VCALENDAR ever be different from that of the VQUERY??

Hmm, are you trying to use a stored VQUERY from a someone elses calendar, is that it??

>     For a create the "TARGET" property MUST NOT be supplied as the
>     destination container is already supplied in the "TARGET" property of
>     the "VCALENDAR" component.
This I grok and agree with...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0076BA7785256C87_=-- From owner-ietf-calendar@mail.imc.org Fri Dec 6 16:55:57 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26467 for ; Fri, 6 Dec 2002 16:55:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB6Lk4203397 for ietf-calendar-bks; Fri, 6 Dec 2002 13:46:04 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6Ljxg03392 for ; Fri, 6 Dec 2002 13:46:00 -0800 (PST) In-Reply-To: <3DF0E4C0.9020800@Royer.com> To: ietf-calendar@imc.org Subject: Re: Expiring of LATENCY MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 6 Dec 2002 16:45:48 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 12/06/2002 04:45:53 PM, Serialize complete at 12/06/2002 04:45:53 PM Content-Type: multipart/alternative; boundary="=_alternative 00779C6585256C87_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00779C6585256C87_= Content-Type: text/plain; charset="US-ASCII" Doug wrote on 12/06/2002 12:56:16 PM: > How about: > > If a CS can start sending the reply to a command > prior to the "LATENCY" timeout value, then the "LATENCY" > time has not expired. Dont forget the text near the top of 10.1.1 that says: If the command is unable to be completed in the specified amount of time (as specified by the "LATENCY" parameter value), then a "TIMEOUT" command MUST BE sent on the same channel to which there MUST BE a an "ABORT" or a "CONTINUE" command reply. where it talks about command completion too... Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 00779C6585256C87_= Content-Type: text/html; charset="US-ASCII"
Doug wrote on 12/06/2002 12:56:16 PM:
> How about:
>
>    If a CS can start sending the reply to a command
>    prior to the "LATENCY" timeout value, then the "LATENCY"
>    time has not expired.
Dont forget the text near the top of 10.1.1 that says:

                                   If the command is unable to be
  completed in the specified amount of time (as specified by the
  "LATENCY" parameter value), then a "TIMEOUT" command MUST BE sent on
  the same channel to which there MUST BE a an "ABORT" or a "CONTINUE"
  command reply.

where it talks about command completion too...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 00779C6585256C87_=-- From owner-ietf-calendar@mail.imc.org Fri Dec 6 16:58:29 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26642 for ; Fri, 6 Dec 2002 16:58:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB6LodI03562 for ietf-calendar-bks; Fri, 6 Dec 2002 13:50:39 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6LoYg03557 for ; Fri, 6 Dec 2002 13:50:35 -0800 (PST) In-Reply-To: <3DF0E977.3060802@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: [Fwd: Re: CAP ABNF and external references]] MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 6 Dec 2002 16:50:15 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 12/06/2002 04:50:28 PM, Serialize complete at 12/06/2002 04:50:28 PM Content-Type: multipart/alternative; boundary="=_alternative 0078046F85256C87_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 0078046F85256C87_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 12/06/2002 01:16:23 PM: > No. I am saying I agree that zero has no meaning - I'll fix that. Then please add some prose to clearly codify the no bounded latency case. Its never directly addressed in the text. A simple line or two along the lines of: If no LATENCY parameter is supplied the the command is not bounded and never expires. and possibly a blurb about command termination too. Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 0078046F85256C87_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 12/06/2002 01:16:23 PM:
> No. I am saying I agree that zero has no meaning - I'll fix that.
Then please add some prose to clearly codify the no bounded latency case.  Its never directly addressed in the text.  A simple line or two along the lines of:

  If no LATENCY parameter is supplied the the command is not bounded
  and never expires.

and possibly a blurb about command termination too.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 0078046F85256C87_=-- From owner-ietf-calendar@mail.imc.org Fri Dec 6 17:05:12 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26939 for ; Fri, 6 Dec 2002 17:05:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB6LugX03935 for ietf-calendar-bks; Fri, 6 Dec 2002 13:56:42 -0800 (PST) Received: from ace.iris.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6Lubg03929 for ; Fri, 6 Dec 2002 13:56:38 -0800 (PST) In-Reply-To: <3DF0F0E0.60807@Royer.com> To: "ietf-calendar@imc.org" Subject: Re: CAP ABNF and external references MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_09262002NP September 26, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com Date: Fri, 6 Dec 2002 16:56:19 -0500 X-MIMETrack: Serialize by Router on Ace/Iris(Release 6.0NP|September 26, 2002) at 12/06/2002 04:56:31 PM, Serialize complete at 12/06/2002 04:56:31 PM Content-Type: multipart/alternative; boundary="=_alternative 007892E885256C87_=" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 007892E885256C87_= Content-Type: text/plain; charset="US-ASCII" Doug replied on 12/06/2002 01:48:00 PM: > I'll add: > > If LATENCY is not specified, then the initiator is indicating > that any timeouts are up to the responder. That works (and you can ignore the like repsonse I sent on another thread a few min ago...). Thanks. > > This case is not described in 09-submitted and I think it needs to be > > before this confusion can be considered resolved. Section 10.1.1 > > Bounded Latency covers many permuations but there is no talk of > > returning partial results. This needs to be covered in text in 10.1.1 > > where latency is covered. > > Sure it is: > > If a CS can both start sending the reply to a command and guarantee > that all of the results can be sent from a command (short of > something like network or power falure), prior to the "LATENCY" > timeout value, then the "LETENCY" time has not expired. Sorry but that text does NOT cover partial results. It clearly says "guarantee that _all_ of the results" (my emphasis) and that is definitely NOT partial results! Perhaps you are thinking that "all results" simply indicate that its a partial result and that another try is necessary??.. (Please say no... Please!) > (the above text being re-writted see separate e-mail on this list) The rewrite does address this concern so I think we are all set here (although we greatly digressed from the initial topic of ABNF and external refernces we did resolve an issue so its worth it). FMI: Whats the new ABNF for latency-sec? Did you use 1..(~68 years) or did you use something else? Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 007892E885256C87_= Content-Type: text/html; charset="US-ASCII"
Doug replied on 12/06/2002 01:48:00 PM:
> I'll add:
>
>    If LATENCY is not specified, then the initiator is indicating
>    that any timeouts are up to the responder.
That works (and you can ignore the like repsonse I sent on another thread a few min ago...).  Thanks.

>  > This case is not described in 09-submitted and I think it needs to be
>  > before this confusion can be considered resolved.  Section 10.1.1
>  > Bounded Latency covers many permuations but there is no talk of
>  > returning partial results.  This needs to be covered in text in 10.1.1
>  > where latency is covered.
>
> Sure it is:
>
>      If a CS can both start sending the reply to a command and guarantee
>      that all of the results can be sent from a command (short of
>      something like network or power falure), prior to the "LATENCY"
>      timeout value, then the "LETENCY" time has not expired.
Sorry but that text does NOT cover partial results.  It clearly says "guarantee that _all_ of the results" (my emphasis) and that is definitely NOT partial results!  Perhaps you are thinking that "all results" simply indicate that its a partial result and that another try is necessary??..  (Please say no... Please!)

>     (the above text being re-writted see separate e-mail on this list)
The rewrite does address this concern so I think we are all set here (although we greatly digressed from the initial topic of ABNF and external refernces we did resolve an issue so its worth it).

FMI: Whats the new ABNF for latency-sec?  Did you use 1..(~68 years) or did you use something else?

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

--=_alternative 007892E885256C87_=-- From owner-ietf-calendar@mail.imc.org Fri Dec 6 19:13:43 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02418 for ; Fri, 6 Dec 2002 19:13:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB704YW15766 for ietf-calendar-bks; Fri, 6 Dec 2002 16:04:34 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB704Vg15758 for ; Fri, 6 Dec 2002 16:04:31 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gB704XC0014315 for ; Fri, 6 Dec 2002 16:04:33 -0800 Message-ID: <3DF13B0B.1050507@Royer.com> Date: Fri, 06 Dec 2002 17:04:27 -0700 From: Doug Royer Reply-To: ietf-calendar@imc.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: What good are stored VQUERYs? References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010102070207010204000404" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms010102070207010204000404 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug noted on 12/05/2002 01:25:17 PM: > > For a search, if the "TARGET" property is supplied in a "VQUERY" > > component, then the CS is to search for the query in the calid > > supplied by the "TARGET" property value. > if I stored the QUERY? Why isnt the TARGET from the VCALENDAR > sufficient to find the VQUERY in RELCALID01? Only when the stored query is in the current TARGET. The VQUERY TARGET is for when it is not - I'll update the draft to say that TARGET is used in the VQUERY when the stored QUERY is not in the CMD-TARGET. > Hmm, are you trying to use a stored VQUERY from a someone elses > calendar, is that it?? Yes - see this WG list over the last few months. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms010102070207010204000404 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIwNzAwMDQyN1owIwYJKoZIhvcNAQkEMRYEFHhFyoAo 1LrLMFMvbEWIWHsozQtpMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQA8rsFN7ljk/uJ9PnYT q5aNr4ikmklaETTiRtAR6oA6PgR9m+9fExmj9ZzkilXiIgv27DYZ2EJFU4W+YienLUOs3ycv qK4imAI+c8xdt8Ov857pGTiUj+6NzbXQthZVMWoKLZVuAJwUBd1D5f/RjtPQlDpkSkt6idLx qq7OHINV3JHnuXD0IyYR56OVOPLSV+8GsWVpYB0RSvQA4hbhwnOo7IZnWOsbLu0eDREppWr0 W3AiaIkgrkhZPfMNI2+gxE+zcTEzq3XJ+mhRbNy8AG8jGeZe90ZWRFlStQIZ8YlTmRCauuJ6 QSePzWp3kCk4UDtLZpHLJRa94qjS+MSD9MvQAAAAAAAA --------------ms010102070207010204000404-- From owner-ietf-calendar@mail.imc.org Fri Dec 6 19:14:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02438 for ; Fri, 6 Dec 2002 19:14:07 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB708fC16000 for ietf-calendar-bks; Fri, 6 Dec 2002 16:08:41 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB708cg15996 for ; Fri, 6 Dec 2002 16:08:38 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gB708dC0014350 for ; Fri, 6 Dec 2002 16:08:39 -0800 Message-ID: <3DF13C01.50109@Royer.com> Date: Fri, 06 Dec 2002 17:08:33 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: CAP ABNF and external references References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030700070501020103080506" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030700070501020103080506 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > Sorry but that text does NOT cover partial results. Please explain 'partial results' and where it is in the draft. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030700070501020103080506 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIwNzAwMDgzM1owIwYJKoZIhvcNAQkEMRYEFNvbXER3 PBeMQcLF/RcHod+aZUkwMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQC9khtRmojmJ5CNupUL dVVb+XVCu/u57juHm369eBSJRWcE8iyeKmYjUuoDvFRBIjrt/Oe6/u679LtTwMv52r5yuDjZ G6JqFgBS4nsWAbNOtY4tXl4bI9Os8ya7IZ6olXI4bsrYjpBOzIzW4J7SC5l2Ugc9RJgFDeVh gcdWBg9YFsGPGDKN1QXO6ccueDRRH30AhVjHzcsvb1NIjbS8eIJbAljz6B7jOw6sXzNWT9E7 q78aidzqzE28+sk+Rj+Mr9mVnxKn4F0QYJ94nqZgRabmXlbdo1FBXQAMlpz4Gf8N0uXaFDlw QcLi1JnOSkaGq9ZaiNtVGHM+WrW77l4tukRRAAAAAAAA --------------ms030700070501020103080506-- From owner-ietf-calendar@mail.imc.org Fri Dec 6 19:16:59 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02526 for ; Fri, 6 Dec 2002 19:16:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB706XW15946 for ietf-calendar-bks; Fri, 6 Dec 2002 16:06:33 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB706Vg15942 for ; Fri, 6 Dec 2002 16:06:31 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gB706WC0014338 for ; Fri, 6 Dec 2002 16:06:33 -0800 Message-ID: <3DF13B83.8060902@Royer.com> Date: Fri, 06 Dec 2002 17:06:27 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: Re: [Fwd: Re: [Fwd: Re: CAP ABNF and external references]] References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030308040804060305040402" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030308040804060305040402 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce_Kahn@notesdev.ibm.com wrote: > > Doug replied on 12/06/2002 01:16:23 PM: > > No. I am saying I agree that zero has no meaning - I'll fix that. > > Then please add some prose to clearly codify the no bounded latency > case. Its never directly addressed in the text. A simple line or two > along the lines of: > > If no LATENCY parameter is supplied the the command is not bounded > and never expires. > and possibly a blurb about command termination too. All commands ether return the data you asked for or an error(s). -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030308040804060305040402 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIwNzAwMDYyN1owIwYJKoZIhvcNAQkEMRYEFJi0sxTQ Fr6e9cz0yD4c04bOGJfyMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQBYltZK6Y+y5TWC76fz v+7fYa4BDm3R+BrSMgnCehOVOunoolphkh+z+bIia9hDUeTunUuXVFDQmOWFOA9S/qEmb+QP MyFQn6LS16aZl8hn6x2C2Lcw7GbYufs824BjP4fRHsFgnZ0eKutQEDFOzXrr0oKo0MonqZas QSdAIpzl/H5SWk0lnM8Ydr3PVYqL1pTXYW+EmI8ISb6QUE7/fw+oHbAZEFnyylGvqDrOQRY7 Y6LTvXRhJOdlUBiTTnSutnQnniJB+xRkzp4zN7tvBgF/EbeA34KMyDaX1lIhqMb6Pm2hUV/b yzyWVodDl4R/ZsUXphN1CDr/3N2rxEqVydcKAAAAAAAA --------------ms030308040804060305040402-- From owner-ietf-calendar@mail.imc.org Sun Dec 15 21:08:03 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13830 for ; Sun, 15 Dec 2002 21:08:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBG1mCf22380 for ietf-calendar-bks; Sun, 15 Dec 2002 17:48:12 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.169.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBG1mAE22376 for ; Sun, 15 Dec 2002 17:48:10 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id BCD62443E for ; Sun, 15 Dec 2002 20:46:52 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions Subject: Fwd: Broken Mozilla X- properties? Date: Sun, 15 Dec 2002 20:44:53 -0500 User-Agent: KMail/1.5 To: ietf-calendar@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200212152044.53032.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, The Mozilla website has presented me iCal for holidays that I believe is broken: BEGIN:VCALENDAR VERSION :2.0 PRODID :PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.0//EN BEGIN:VEVENT UID :902705443 SUMMARY :Canada Day CLASS :PRIVATE X ;MEMBER=AllDay :TRUE If I read RFC 2445 properly, the X- property MUST contain at least one character after "X-". Did I read this properly? The X- properties MUST have 1 or more characters after "X-" : x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") ; Reservered for experimental use. Not intended for use in ; released products. vendorid = 3*(ALPHA / DIGIT) ;Vendor identification -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ From owner-ietf-calendar@mail.imc.org Sun Dec 15 21:08:06 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13833 for ; Sun, 15 Dec 2002 21:08:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBG1l7f22363 for ietf-calendar-bks; Sun, 15 Dec 2002 17:47:07 -0800 (PST) Received: from ns1.webservicesolutions.com (ns1.webservicesolutions.com [66.11.169.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBG1l2E22359 for ; Sun, 15 Dec 2002 17:47:04 -0800 (PST) Received: from laptop.home2.mark (CPE014500005442.cpe.net.cable.rogers.com [24.114.109.19]) by ns1.webservicesolutions.com (Postfix) with ESMTP id 7299D443B for ; Sun, 15 Dec 2002 20:45:45 -0500 (EST) From: Mark Swanson Organization: Web Service Solutions To: ietf-calendar@imc.org Subject: Re: Is Apple creating invalid iCalendar? Date: Sun, 15 Dec 2002 20:43:45 -0500 User-Agent: KMail/1.5 References: <200212151224.44953.mark@WebServiceSolutions.com> In-Reply-To: <200212151224.44953.mark@WebServiceSolutions.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200212152043.45560.mark@WebServiceSolutions.com> Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, I'm looking at RFC 2445 messages that appear to be created by Apple (prodid) and the X- properties appear to be incorrect. RFC 2445 states: x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") ; Reservered for experimental use. Not intended for use in ; released products. vendorid = 3*(ALPHA / DIGIT) ;Vendor identification This tells me that (if present) the vendorid MUST be at least 3 characters. The snippet below shows they are creating X- properties with 2-character vendorids. Would anyone disagree with this analysis? BEGIN:VCALENDAR CALSCALE:GREGORIAN X-WR-TIMEZONE;VALUE=TEXT:Canada/Eastern X-WR-CALDESC;VALUE=TEXT:Tentative schedule as of Nov.13\, 2002 PRODID:-//Apple Computer\, Inc//iCal 1.0//EN X-WR-CALNAME;VALUE=TEXT:Formula 1 2003 X-WR-RELCALID;VALUE=TEXT:A5DE1AC4-FE55-11D6-8BC3-003065D59122 VERSION:2.0 -- Schedule your world with ScheduleWorld.com http://www.ScheduleWorld.com/ From owner-ietf-calendar@mail.imc.org Mon Dec 16 12:57:36 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12297 for ; Mon, 16 Dec 2002 12:57:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBGHl6e13194 for ietf-calendar-bks; Mon, 16 Dec 2002 09:47:06 -0800 (PST) Received: from eeyore.jsoft.com (24-240-234-245.charter.com [24.240.234.245]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBGHl1o13190 for ; Mon, 16 Dec 2002 09:47:04 -0800 (PST) Received: from jsoft.com (IDENT:1JeOMauXsD2XjOHv8xqNzMCTKbONPFdG@eeyore.jsoft.com [192.168.0.46]) by eeyore.jsoft.com (8.11.6/8.11.0) with ESMTP id gBGGbZ717300; Mon, 16 Dec 2002 10:37:36 -0600 Message-ID: <3DFE014F.4010206@jsoft.com> Date: Mon, 16 Dec 2002 10:37:35 -0600 From: Gary Frederick Organization: Jefferson Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Swanson CC: ietf-calendar@imc.org Subject: Re: Fwd: Broken Mozilla X- properties? References: <200212152044.53032.mark@WebServiceSolutions.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Look at http://bugzilla.mozilla.org/show_bug.cgi?id=129660 http://bugzilla.mozilla.org/show_bug.cgi?id=129660#c6 The Mozilla calendar project knows it's wrong, and needs someone to spent the time to fix it. So many interesting projects, 24 hours in the day. Gary Mark Swanson wrote: > Hello, > > The Mozilla website has presented me iCal for holidays that I believe is > broken: > > BEGIN:VCALENDAR > VERSION > > :2.0 > > PRODID > > :PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.0//EN > > BEGIN:VEVENT > UID > > :902705443 > > SUMMARY > > :Canada Day > > CLASS > > :PRIVATE > > X > ;MEMBER=AllDay > > :TRUE > > If I read RFC 2445 properly, the X- property MUST contain at least one > character after "X-". Did I read this properly? > > The X- properties MUST have 1 or more characters after "X-" : > > x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") > ; Reservered for experimental use. Not intended for use in > ; released products. > > vendorid = 3*(ALPHA / DIGIT) ;Vendor identification > > From owner-ietf-calendar@mail.imc.org Tue Dec 17 04:59:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10549 for ; Tue, 17 Dec 2002 04:59:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBH9mvs00641 for ietf-calendar-bks; Tue, 17 Dec 2002 01:48:57 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBH9mso00622 for ; Tue, 17 Dec 2002 01:48:56 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id A254915528; Tue, 17 Dec 2002 10:48:48 +0100 (CET) Date: Tue, 17 Dec 2002 10:48:48 +0100 From: Andrea Campi To: ietf-calendar@imc.org Subject: 12.2 BEEP Exchange Styles Message-ID: <20021217094848.GJ93256@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, I was wondering about this: A CAP request, targeted at more than one containers, MAY use a one- to-many exchange, with a distinct answer associated with each target. CAP request targeted at a single container MAY use a one-to-one exchange or a one-to-many exchange. Maybe it's me, but I don't understand if the difference in the wording between the two sentences is intentional. If it isn't, I guess we should either merge the two or make them identical. If it is, however, then I don't understand the first one. Is it supposed to be a MUST? Now that I think of it, it makes no sense anyway: we're mixing request and answer. What about: An answer to a CAP request, targeted at more than one containers, ... Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Tue Dec 17 23:45:41 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02229 for ; Tue, 17 Dec 2002 23:45:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBI4etj15973 for ietf-calendar-bks; Tue, 17 Dec 2002 20:40:55 -0800 (PST) Received: from imc.org ([210.21.34.191]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBI4ero15968 for ; Tue, 17 Dec 2002 20:40:53 -0800 (PST) Message-Id: <200212180440.gBI4ero15968@above.proper.com> From: x0152@sina.com.cn Subject: =?GB2312?B?zOG5qc34wufJ48/xu/o=?= To: ietf-calendar@imc.org Content-Type: text/plain;charset="GB2312" Reply-To: bobmah@mit.edu Date: Wed, 18 Dec 2002 12:44:28 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ---- No: 20173 你好 我们是深圳香归电子有限公司 我们提供网络摄像机及监控系统的安装调试 网络摄像机作为下一代商业应用程序的超级平台，它都为 Web 专业人士提供了前所未有的功能。 为管理企业应用程序提供了运行时间环境和图示管理工具。 如有需要请与广州办事处联系　 电话：020－82349026 赵巧辉 公司网址www.xianggui.com 邮件：zhaoqiaohui@xgjk.sina.com.cn From owner-ietf-calendar@mail.imc.org Wed Dec 18 04:32:58 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00677 for ; Wed, 18 Dec 2002 04:32:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBI9Q9K25398 for ietf-calendar-bks; Wed, 18 Dec 2002 01:26:09 -0800 (PST) Received: from acampi.inet.it ([213.92.1.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBI9Q8o25393 for ; Wed, 18 Dec 2002 01:26:09 -0800 (PST) Received: by acampi.inet.it (Postfix, from userid 210) id EDDAB15507; Wed, 18 Dec 2002 10:26:03 +0100 (CET) Date: Wed, 18 Dec 2002 10:26:03 +0100 From: Andrea Campi To: ietf-calendar@imc.org Subject: VTIMEZONE in CAP Message-ID: <20021218092603.GL93256@inet.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: I.NET S.p.A. User-Agent: Mutt/1.5.1i Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, how do you people expect CAP to change the way VTIMEZONE are handled according to previous standards? Section 4.2.19 of [iCalendar]: The value of the TZID property parameter will be equal to the value of the TZID property for the matching time zone definition. An individual "VTIMEZONE" calendar component MUST be specified for each unique "TZID" parameter value specified in the iCalendar object. and section 3.1 of [iTIP]: DateTime values MAY refer to a "VTIMEZONE" component. The property restrictions in the table below apply to any "VTIMEZONE" component in an ITIP message. Component/Property Presence ------------------- ---------------------------------------------- VTIMEZONE 0+ MUST be present if any date/time refers to timezone For BOOKED components, iTIP is irrelevant, but when storing or retrieving iTIP components I would expect 3.1 of iTIP to be mandatory. So we need to always include the VTIMEZONEs the component(s) specify? This seems to be a little bit absurd to me: the CUA only needs to be able to retrieve the VTIMEZONEs from the CS; it can do so once per session (and even cache them between sessions). I propose we amend 3.1 and interpret 4.2.19 to mean all the VTIMEZONEs must exist in the CAP store. To accomodate simple-minded CUAs, they MAY appear in iTIP objects exchanged between the parties. What do you think? Bye, Andrea -- Andrea Campi mailto:a.campi@inet.it I.NET S.p.A. - BT Ignite http://www.inet.it Technical Dept. - R&D phone: +39 02 32863 ext 1 v. Darwin, 85 - I-20019 fax: +39 02 32863 ext 7705 Settimo Milanese (MI), Italy From owner-ietf-calendar@mail.imc.org Thu Dec 26 17:23:04 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16580 for ; Thu, 26 Dec 2002 17:23:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBQMEVL20635 for ietf-calendar-bks; Thu, 26 Dec 2002 14:14:31 -0800 (PST) Received: from royer.com (inet-consulting.com [4.23.9.166]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBQMEUo20628 for ; Thu, 26 Dec 2002 14:14:30 -0800 (PST) Received: from Royer.com (inet-products.com [12.42.147.70]) by royer.com (8.12.2/8.12.2) with ESMTP id gBQMELFQ020656 for ; Thu, 26 Dec 2002 14:14:31 -0800 Message-ID: <3E0B7F38.4000608@Royer.com> Date: Thu, 26 Dec 2002 15:14:16 -0700 From: Doug Royer Reply-To: "ietf-calendar@imc.org" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" Subject: CAP - next version Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030604080908000201020302" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms030604080908000201020302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This weekend my plans are to take the WG advice and rearrange the CAP draft. Mostly eliminating duplicate text and sections. In this next pre-release version I do not want to make any changes except typos and reorganizing CAP. Then in a week or so when that is settled :-) move on to any outstanding technical issues. Comments? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- Doug@Royer.com | Office: (208)612-INET http://Royer.com/People/Doug | Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards --------------ms030604080908000201020302 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINRDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJPKEwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDIwOTE4MDAw MDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD EEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuOjEp298xKmKaSoPmY4WupTfjVMvob cj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umSqlGIEwX6u2g2lfhJIG1nAYCAItpB JXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzvq3gGiEg4kjV+KC+peZLB9YpiuEFx 3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvfvMcUKdzRub3F/GNvDgu6dd1Jq52t VrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJJKkkZRaZAgMBAAGjggEGMIIBAjAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQF AAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9ttwSYnVsHPS1PcjLxGL5gSrWxN1G VNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcUioomgeYc81cGfR1diWN7mnZNFuXZ Ztb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jCCBOswggRUoAMCAQICEB6MU1BH+lj1qKUyvJWJ PKEwDQYJKoZIhvcNAQEEBQAwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQwHhcNMDIwOTE4MDAwMDAwWhcNMDMwOTE4MjM1OTU5WjCCAQsxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixM SUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsT KkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQK RG91ZyBSb3llcjEdMBsGCSqGSIb3DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDDEEdQIl3XiWTOQkkpItylRI2rKbxVg1IzkcQpZ2/jcVuO jEp298xKmKaSoPmY4WupTfjVMvobcj8qS9D1PMZamtivKL+om94xqHo/Psc9A57ibZiV5umS qlGIEwX6u2g2lfhJIG1nAYCAItpBJXuMDpDICIS/n9A9hjkpwD03cjg96YSgLmRLWM8PvHzv q3gGiEg4kjV+KC+peZLB9YpiuEFx3+1c2TrxWk6pQ5lK5Kuf5EccoS4hLZ46PbzkgCfRbqvf vMcUKdzRub3F/GNvDgu6dd1Jq52tVrlR1hLGRODEXhaBfCHcl9kzyKhEJURI3cOmyApulYVJ JKkkZRaZAgMBAAGjggEGMIIBAjAJBgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG +EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIG CCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhC AQEEBAMCB4AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xh c3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCghngGsGOsnFS9lbtsCZbIesZa/6gF92Q48YG9 ttwSYnVsHPS1PcjLxGL5gSrWxN1GVNanVdMqjz+F8K53NtGpQ3YI1yiOQEDLTMfeGJbIUOcU ioomgeYc81cGfR1diWN7mnZNFuXZZtb+G+kzUOy0ciHI4HlZp0gLXjGatLrp4jGCA7UwggOx AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQ QSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xh c3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAe jFNQR/pY9ailMryViTyhMAkGBSsOAwIaBQCgggGoMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTIyNjIyMTQxNlowIwYJKoZIhvcNAQkEMRYEFDAg73I2 TH7KYnMBvmxWzBjUUWlXMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIH0BgsqhkiG 9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZAIQHoxTUEf6WPWopTK8lYk8oTANBgkqhkiG9w0BAQEFAASCAQC8Hsc5u4+FiX12JKCe VA4/UNrCozsKoYDiIEi3y4u+zkCeb/zEEY7hDCXzafWYQKZCkEfsAgTC5Grm5ZN/Y5lyuMnl uZMJONpLgN08pm3ZEmYvmwVScmFgDnzN59hwlCHVvbh6cgQ+Bx79nkrcNKcXmGqqJPjW8wFr F8VxlkzhUSagFS/nZM/FyYy8KJdEMvp+41SRzXSQEn2gyqna294tShKSLolTwRqAGtrYAkcW y6JiATRpvumUK+991wjyfVlfmlcc8UlsNfC6Gbkq7/7wmgpNW5ggbclWH3zTeiKNMj/IgvIz aMPyYJxpKxx5I02aeCN+P9XSv9ScrAgvTr7RAAAAAAAA --------------ms030604080908000201020302-- From owner-ietf-calendar@mail.imc.org Thu Dec 26 18:11:30 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17185 for ; Thu, 26 Dec 2002 18:11:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBQN8pE23885 for ietf-calendar-bks; Thu, 26 Dec 2002 15:08:51 -0800 (PST) Received: from smtp02.symbian.com (smtp02.symbian.com [212.133.29.133]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBQN8oo23881 for ; Thu, 26 Dec 2002 15:08:50 -0800 (PST) Received: from symbianuk05.intra (unverified) by smtp02.symbian.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Thu, 26 Dec 2002 23:05:03 +0000 Subject: Chris Dudding is out of the office. From: Chris.Dudding@symbian.com To: "ietf-calendar@imc.org" Message-ID: Date: Thu, 26 Dec 2002 23:07:36 +0000 X-MIMETrack: Serialize by Router on SymbianUK05/Symbian(Release 5.0.8 |June 18, 2001) at 26/12/2002 23:07:44 MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Sender: owner-ietf-calendar@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I will be out of the office starting 23/12/2002 and will not return until 06/01/2003. I will reply to your message when I return. ********************************************************************** Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK. This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify postmaster@symbian.com and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy. **********************************************************************