Subject: Editors notes 8-MAY-02

From: Doug Royer <[email-masked]>
Date: Mon, 06 May 2002 14:54:21 -0600

(long)

You will not see these changes below until we push a new version
of the draft. If the chairs are okay with it, I can publish
on a web site the interm-working-version?

I spent some more time working on and catching up to all
of the WG comments that have not been acted upon. I added 
several things - many edits. Some were implied on the WG list,
others were explicit:

Mandated that the CAPABILITIES reply always be in UTF-8.

  This allows CUA's to determine the LOCALE's and CHARSET's

  the CS supports. Without this requirement, there is NO
  way to determine which charset and locale the CAPABILITIES
  the CS is running at the moment (Thus making the command
  unreadable to the CS and the reply unreadable to the CUA).
  This was not explicitly discussed. But there have been NO
  proposals as this seemed as good as any.

Mandated that upon initial connection, the CS be using the
UTF-8 charset.

   There needed to be a MUST charset specified and a
   starting point to switch (see below).

Added a requirement that the CUA AND CS can only send
data using the locales defined in the initial beep greeting.
Not explicitly talked about on the list.

Added a CHARSET command so that CUA's can change the charset
to one of the ones returned in CAPABILITIES and mandated
that the charset command AND reply always be in UTF-8.

  Without this there was NO way to switch charsets at all.
  As the MIME header is NOT sufficient. You can't read
  the MIME header charset setting if it is already in
  another charset.

  This was so that the CUA can change and use any charset
  supported by both the CS and CUA. Without this command
  there was no way to switch from/to UTF-8.

  This had been debated in the past. Mostly asian concerts
  about wanting to use their popular charset. This adds that
  discussed capability to CAP.

Included in the charset command is a locale (LANG) property
that allows the CUA to specify both the charset and locale
the CUA and CS use. And that the values MUST BE from
the BEEP greeting and CS capabilities replied.

  Like this:

        CMD:charset
	LANGUAGE:xx_yy
	CHARSET:zz

We DID talk about being able to do this, there was not specific
proposal - I added the above to CAP and you will see it in the
next release.

Added several defaults values to the VCALSTORE and VAGENDA
properties lists. There needed to be default for LANG and LOCALE
as discussed on the list. No specifics were proposed and
without them, the CUA had no way to know which ones the CS supported.
Plus there was no need to force all VAGENDAs on a CS to
be in the same locale and charset - *IF* the CS supports
more than one charset/locale. If the CS only supports UTF-8,
then those will just be set to UTF-8.

I again trimmed down the restriction tables and specified
which section in iCal, iTIP, iMIP, or CAP information
is specified in. This was because it was simply duplicate
information and the comments were getting long explaining
what was already explained in another rfc or section of CAP.

I removed almost all of the BEEP headers and footers from the examples.
We use BEEP, that was already explained in the CAP.

I started to update the reply codes (more TBD).

I changed OWNER to OWNER() so there were not two ways
to specify the owner. I changed NONOWNER to NONOWNER() - same
as above.

I changed 'user@*' to say 'Not recommended". I would like
to say "not valid". Per the list discussion.

I added missing property, parameter, and value definitions
in their own sections - (more TBD).

I edited the change control to say 'submit draft for RFC approval...'
There has been no justification for a 'method reviewer' and
there has been much debate about how to structure it. So I changed
it to what every other RFC does - tell them to generate an RFC.
If they want to add to 2445, then follow those procedures.

--------
(amplification of stuff above)

I added "DEFAULT-CHARSET" to the VCALSTORE - needed if you need to know.
I added "DEFAULT-LOCALE" to the VCALSTORE - needed if you need to know.
I added "RELATED-TO" to the VCALSTORE - per list talk months ago.

I added "DEFAULT-CHARSET to the VAGENDA - needed if you need to know.
I added "DEFAULT-LOCALE" to the VAGENDA - needed if you need to know.
I put in "RELATED-TO" to the VAGENDA - per list talk months ago.
---------

Next: I am going to re-arrange CAP so the definitions of the
new properties, parameters, and values exist prior to their
usage.

-Doug

---

From: "John Stracke" <[email-masked]>
Date: Mon, 6 May 2002 17:48:19 -0400

>on a web site the interm-working-version?

If you've got the interim version, wouldn't it be just as easy to submit 
it as an I-D? It'd be good for anybody looking in the I-D repository to 
see the latest version.

>Mandated that the CAPABILITIES reply always be in UTF-8.

Makes sense to me.

>to say "not valid". Per the list discussion.

I think you're right; it should be invalid--it's just as weak as 
anonymous.

>it to what every other RFC does - tell them to generate an RFC.

I like it (not that I think that will surprise anybody ;-).

/========================================================\
|John Stracke                    |Principal Engineer     |
[email-masked]   |Incentive Systems, Inc.|
|http://www.incentivesystems.com |My opinions are my own.|
|========================================================|
|"What a plan! Simple, yet insane!" -- _Monsters, Inc._  |
\========================================================/