Subject: CAP-12-e: Changing REQUEST-STATUS

From: [email-masked]
Date: Mon, 10 Nov 2003 10:12:40 -0500

In looking up something related to CALSCALE I noticed that CAP-12-e makes 
an unmentioned change to iCalendars REQUEST-STATUS property.  This change 
is NOT good NOR is it necessary.

iCalendar defines REQUEST-STATUS as:

   Format Definition: The property is defined by the following notation:

     rstatus    = "REQUEST-STATUS" rstatparam ":"
                  statcode ";" statdesc [";" extdata]

CAP-12-e proposes changing it to:

   rstatus  = "REQUEST-STATUS" rstatparam ":"
              statcode ";" *(statdesc ) ";" *(extdata)

This makes statdesc optional now PLUS it makes statdesc and extdata both 
multi valued.  This is a non-backwards compatible change for no apparent 
reason that I can find in a quick archive search on the topic.  These 
changes to REQUEST-STATUS seem to serve no pratical purpose (What good are 
2 "status descriptions" values for 1 REQUEST-STATUS?).  Plus they change 
the legal possible values the property can have which may make iCalendar 
parsers treat the property as incorrectly formed and thus 'invalid'.

"Extending" REQUEST-STATUS for CAP is to be expected but making a 
fundamental change to the property is NOT.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Mon, 10 Nov 2003 12:54:21 -0700

I remember at or before -00 time, we had a problem with the iCAL
version of REQUEST-STATUS and how it effected some error handling.
Fixing REQUEST-STATUS was one of the todo items for CAP.
Still looking through archives...

I am guessing it was just fixed incorrectly and no one noticed since -08.

As in -07 it was incorrectly:

        statcode [";" statdesc [";" extdata]]

I am guessing the incorrect ABNF got incorrectly fixed.

[email-masked] wrote:

>
> In looking up something related to CALSCALE I noticed that CAP-12-e 
> makes an unmentioned change to iCalendars REQUEST-STATUS property. 
>  This change is NOT good NOR is it necessary. 

If you would have looked closer it was not mentioned in -12-e becaues it 
did not
change in -12-e.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                               |   Cell: (208)520-4044

               We Do Standards - You Need Standards

---

From: Doug Royer <[email-masked]>
Date: Mon, 10 Nov 2003 17:36:41 -0700

I think it is supposed to be:

    statcode ";" [ statdesc ] ";" [extdata]

Doug Royer wrote:

> If you would have looked closer it was not mentioned in -12-e becaues 
> it did not
> change in -12-e.
>
>

--

---

From: [email-masked]
Date: Tue, 11 Nov 2003 13:35:38 -0500

>     statcode ";" [ statdesc ] ";" [extdata]

The change was originally proposed by George back on 08/18/2000 04:46:33 
PM AST with the justification label of:

Changes needed by CAP.

When I asked about this need there was no response and thats where it was 
left on 22-Aug-2000. 

Doug had referred to a concern about the language of the contents of 
statdesc but thats secondary to the proposed change (and would affect ALL 
properties in iCal, not just stadesc on REQUEST-STATUS)

As originally noted in 
http://www.imc.org/ietf-calendar/mail-archive/msg00680.html there is no 
need to revise the ABNF from its current state in order to make statdesc 
optional if you properly follow the ABNF in 2445:

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!   

This proposed change to REQUEST-STATUS essentialy boils down to CAP 
wanting to always have the trailing semicolon to delimit the end of the 
optional statdesc.  That is instead of the current:

REQUEST-STATUS:2.0;

a CAP implementation would have to use:

REQUEST-STATUS:2.0;;

This change would be a non-backwards compatible one too.  If CAP cannot 
demonstrate a need for the ABNF to change in iCalendar, it should not be 
done.  Especially if it will break interop with no particular benefit or 
need.

Bruce

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Nov 2003 12:43:39 -0700

[email-masked] wrote:

> This change would be a non-backwards compatible one too.  If CAP
> cannot demonstrate a need for the ABNF to change in iCalendar, it
> should not be done.  Especially if it will break interop with no
> particular benefit or need.

Don't you find it odd that you declare everyone that took part
in that debate as misunderstanding the topic - except you?

Did it really take you 3 years to notice this? Looking a those
same archives - you participated in that discussion. Could you
at least post a fix once in a while and not just declare that
it was made as you just posted a few days ago:

  (Bruce) "In looking up something related to CALSCALE I noticed
	that CAP-12-e makes an unmentioned change to iCalendars REQUEST-STATUS
	property.  This change is NOT good NOR is it necessary. "

You participated in that debate 3 years ago and yet you seem to
have indicated (above in the full post) that there was a change made
without your or the lists permission. Do you not see how that can
be seen as abusive to this list?

Would you please read the archives and search for topic before posting
more misinformation that causes others to have to do your work and
lookup the history only to find again that you posted an incorrect
history of events. Will you ever be embarrassed by your continual
errors you post?

Can you ever live with something that is not 100% your way?

Lets get CAP out the door. Yes this needs fixed but your post
forced me (and I will bet others) have to re read the archives
only to conclude that your original post had false information.
At least this one you caught before this got into a big debate.
There was no -12-e change to the ABNF - your fears or whatever
are causing this list grief when you cause others to have to lookup
your contributions to see if what you say is valid. So far of your
original posts to a topic you are running about 5% accuracy as
as whole on your first post (I counted from Jan-2003). Causing others
to have to redig over and over again into the archives because you
shoot from the hip.