Subject: RFC 2446 Quickie

From: [email-masked]
Date: Thu, 1 Jun 2000 15:12:11 -0400

In looking at the details of RFC 2446 I noticed what may be either an 
oversight or at least some inconsistancies in the tables of what 
properties are allowed in each message type.

In particular, for a VEVENT under nearly all METHODs except REPLY, CANCEL 
and COUNTER the description for SUMMARY and DESCRIPTION says "Can be 
null".  Is there any reason that for these methods we do NOT allow SUMMARY 
and/or DESCRIPTION to be null as well??

If not, can the current holder of RFC 244x errata and updates please note 
this.  Im sure there are other inconsistancies like this but Im not 
focused on them just yet...

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Mon, 12 Jun 2000 11:33:16 -0400

Bruce:
>In particular, for a VEVENT under nearly all METHODs except REPLY, CANCEL 
and COUNTER the description for >SUMMARY and DESCRIPTION says "Can be 
null".  Is there any reason that for these methods we do NOT allow 
>SUMMARY and/or DESCRIPTION to be null as well?? 

We would use SUMMARY and DESCRIPTION and other properties other than UID 
in REPLY, CANCEL and COUNTER method as secondary techniques to UID to 
match an event. The only reason that I can think of is that we want to 
make sure that if these properties appeared, that they had the matching 
content. Of course, if the property had a NULL value, then the matching 
content would also be NULL.
But that is the only logical reason that I can think of for restricting 
the content length.
Others?
-- Frank

---

From: [email-masked]
Date: Mon, 12 Jun 2000 12:02:19 -0400

Frank replied with:
>We would use SUMMARY and DESCRIPTION and other properties other 
>than UID in REPLY, CANCEL and COUNTER method as secondary 
>techniques to UID to match an event.  The only reason that I can 
>think of is that we want to make sure that if these properties 
>appeared, that they had the matching content. Of course, if the
>property had a NULL value, then the matching content would also 
>be NULL. 

Sounds like RFC 2446 should be updated to have "Can be NULL" for REPLY, 
COUNTER and CANCEL.  Since noone else seems to have voiced any other 
opinion for or against the change, "Make it so Mr. RFC 2446 Errata 
maintainer(s)"...
the content length.

I never mentioned restricting the length, I was merely concerned with the 
discrepancy of the tables under REPLY, CANCEL and COUNTER that did not 
expressly allow for NULL SUMMARY and DESCRIPTION like the other methods 
did.

Bruce