Subject: Re: Consensus? BEEP commands

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 19 Feb 2002 10:18:46 -0500

Doug Royer wrote:
>
> Bernard Desruisseaux wrote:
>
> > ... Furthermore,
> > some of the changes that are part of the proposal, are not
> > only unrelated to the reduction of bytes in BEEP messages,
> > but on the contrary, increase the number of bytes by enforcing
> > duplication of information in messages.

> ...

> About 99% of the changes I sent is what it takes
> to move the data back into the consensus reached iCalendar
> objects stored in a CDATA section  as you describe above.
> What is your point?
> 
> What changes have I made that have not been discussed
> on this list?
> 
> I took and merged the CDATA section and wrapped it
> with the command. This WAS talked about on the WG list.

Changes that are unrelated to the reduction of bytes in
BEEP messages:

- Per your proposal, the Content-Type of BEEP messages was
  changed from application/beep+xml to application/cap+xml.
  This has previously been discussed on the list, but didn't
  reach consensus.

- The VALARM components in your examples makes use of the
  SEQUENCE property.  This has been discussed on the list,
  but didn't reach consensus yet.

- The TRIGGER property of the VALARM components in your
  examples makes use of the ENABLE parameter.  This has
  been discussed on the list, but didn't reach consensus
  yet.

- It has been debated on the mailing list that variables
  introduced by USING_PROPERTIES and USING_COMPONENTS don't
  need the "x-" prefix.  Although these variables MAY have
  the "x-" prefix, the draft should not use the "x-" prefix
  to confuse first time readers uselessly (e.g., why did the
  author prefixed the variable by "x-"?  what am I missing?)

- A new "<components>" capability was added.  I can't recall
  this being discussed on the list.

- The format of the results returned by the modify command,
  is neither in XML, nor in iCalendar, and assumes that all
  components have a UID property, which you have strongly
  opposed to.

Changes that enforces duplication of information in
messages:

- Per your proposal, one needs to specify the command he
  wants to be performed on the CS in the XML portion of
  the BEEP messages, and duplicate this information in
  the METHOD property of the iCalendar object.

- Per your proposal, one needs to duplicate the command
  identifier, already specified in the XML portion, in
  the iCalendar object.

- Per your proposal, one needs to duplicate the target,
  already specified in the XML portion, in the iCalendar
  object.

As can be read in RFC 3117 "if an application protocol
has two ways of doing the exact same thing, then there's
a problem somewhere in the architecture underlying the
design of the application protocol."

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

---

From: Doug Royer <[email-masked]>
Date: Tue, 19 Feb 2002 11:12:56 -0700

>   This has previously been discussed on the list, but didn't

Nor did beep+xml reach consensus - should I have left that blank?
 
>   but didn't reach consensus yet.

Nor did ARLARMID or UID reach consensus - should I have
left that blank?
 And the SEQUENCE idea is *months* old.
Not that that makes it consensus - but there were no
objections to that proposal when it was submitted the first
time - and only one 'good idea' reply when it was re-submitted
the second time. And now the third time, you don't have any
objections to the idea - you simply don't want it in CAP.

>   been discussed on the list, but didn't reach consensus

Yet - one of my assigned tasks was to propose the text
for how to tag VALARMs (or any component) as local. At the
time of the original post (months ago), there was general 
agreement - I don't recall seeing ANY objections. 

>   author prefixed the variable by "x-"?  what am I missing?)

You are missing many posts that says it does not matter
what the name is called. So are you saying that it
matters what the name is? And is  calling it 'attendee' less
confusing than 'x-attendee' when we all know that there is
already an 'ATTENDEE' property? I was confused and there was
a long thread were I was confusing the property name from
the made up name that was spelled exactly the same, others will
also be confused.

In iCalendar the name can be [aA][tT][tT][eE][nN][dD][eE][eE]
The XML talks seem to be going for 'attendee'.
And you want to write in the CAP draft that sometimes 'attendee',
does not mean 'attendee'. I think I removed the confusion.
I do not see how I added any confusion.

>   this being discussed on the list.

Per the e-mail I sent. (1) it *has* been discussed - but not
formally. (2) It was specifically tagged as an exception - I
did not sneak it into the text. (3) Even Steltor has asked me
how to tell which components any CS supports. (4) As stated
in the e-mail - it is trivial to remove. (5) You also don't
seem to have any problem with this <component> capability.
You seem to object that you personally did not agree or
take part or notice the old discussion on this issue.

It has been asked more than once.

>   is neither in XML, nor in iCalendar,

When is it not XML?
 Could it have been a typo? (Typos?)

> and assumes that all

If I did that, I made an error - not planned.

>   the METHOD property of the iCalendar object.

We HAVE beat that to death on this list. There
was NEVER any consensus to remove METHOD from the iCalendar
objects. I was trying to reach a compromise with your co-workers
who also wanted it in the command itself. If you re-read this
list several of your co-workers did agree. I think on this
issue of placing the PROPERTIES back into the iCalendar objects,
as had been agreed - you are the only one that strongly objects.
So I do think there is a consensus on 'this' PROPERTY issue.
Steve Mansour stated that he felt that the data was moving
back into the transport - this is what he meant.

>   identifier, already specified in the XML portion, in

And like METHOD - there was never any consensus to remove CMDID
from the iCalendar object. I am simply fixing the text.
And this HAS been discussed on this list.

>   already specified in the XML portion, in the iCalendar

And like METHOD and CMDID again - there was never any consensus
to remove TARGET from the iCalendar object. I am simply fixing the text.
And this HAS been discussed on this list.

> design of the application protocol."

And real life says - compromise.

The METHOD is also in the iCalendar MIME header, so that one
vendor is happy - to get anything out - sometimes we 
must compromise. I personally see NO need to have the data
in the BEEP command. In my implementation the BEEP layer simply
passes the payload to the CS. Your implementation must be different.
This way we can all get our work done - by having it in both.
And still with this duplication the packets are 1/3 to 1/2 smaller.
Thanks Patrice for the idea!