Subject: Re: Subject: Registration of text/calendar MIME property REQUEST-STATUS

From: [email-masked]
Date: Tue, 22 Aug 2000 10:12:34 -0400

Doug asked:
>>  For the 2.0 "Success" case this may be ok but for all the other the
>> non-2.0 cases where the statdesc may be somewhat useful, a SPACE is not
>> going to cut it.
>
>No text was mandaded for non-2.0 cases, so why is SPACE invalid?

I didnt say "invalid", I was referring to the _usefulness_ of statdesc when I said "cutting it".

Let me be more precise then to avoid any further confusion:  NO contents 
were EVERY mandated for statdesc.  For cases other than 2.0, the _PURPOSE_ 
of statdesc is defeated by anything like SPACE or NULL for contents.  For 
the 2.0 case, statdesc is not that important since its the "Success" case; 
for (nearly?) all other cases statdesc is of some use so a SPACE or NULL 
is NOT a good choice to send (even though you CAN do it by RFC 
defintions).

>Noting in RFC2445 said what was to be sent. No format, no data,
>nothing. So a single SPACE is valid per RFC2445 now.

Read the ABNF for statdesc and you will see "Textual status description".  So while the actual contents of that are not mandated (nor are they 
for LOCATION, CLASS, etc) the _kind_ of data is described.  Its up to 
implementations to put in something useful.  See thoughts above on the 
_intent_ of statdesc if still necessary...

Also, if you really read the ABNF you will see that NULL is also valid!  The ABNF for statdesc is:

     statdesc   = text
     ;Textual status description

and we defined text as:

     text       = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR)

Note the *() format so NULL is already an option.  The only difference 
between this proposal and the one we already have in RFC 2445 is 
effectively to remove the mandated semicolon after the statcode.  Thats 
it! 

If the collective CAP folks are worried about the difference between:

REQUEST-STATUS:2.0;

and

REQUEST-STATUS:2.0

then CAP has other problems than those already raised.  The ABNF change 
suggested really boils down to this 1 character difference! 

So answer will someone please answer WHY this is necessary to make a 
NON-BACKWARDS COMPATIBLE change for this in CAP??  If there is no 
compelling reason then Im vigorously opposed to this proposed change!!

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: Doug Royer <[email-masked]>
Date: Tue, 22 Aug 2000 07:43:49 -0700

[email-masked] wrote:

> NON-BACKWARDS COMPATIBLE change for this in CAP??

The idea was that when nothing is needed, why add something
just to fill in the ABNF. The 'NULL' description would
serve the same purpose.

>  If there is no

I think that "REQUEST-STATUS:2.0;" would be acceptable.

-Doug

---

From: George Babics <[email-masked]>
Date: Mon, 28 Aug 2000 12:38:07 -0400

Doug Royer wrote:

[snip]

> I think that "REQUEST-STATUS:2.0;" would be acceptable.

  Its fine by me also.

  If there are no more objections, I will repost the registration
for the property with the above change.

George