Re: Fwd: beep in calsch-cap-13.txt

Doug Royer wrote:

>>>* use of the "locales"[sic] attribute in the BEEP greeting to set the 
>>>CAP locale might not be the best thing.  the "locales"[sic] attribute 
>>>appears to be for localizing BEEP error messages, and so I am 
>>>unsure how appropriate it would be to re-use it for the CAP 
>>>protocol itself.  I am mainly unsure if implementations typically 
>>>export that information.

>That is also its usage in CAP. For status and error messages. So I 
>think it is valid to use them.

I'm not trying to say that the use of the "localize" attribute isn't valid, 
what I'm trying to say is that it might not be a good idea from an 
implementation standpoint.  From a theoretical perspective, since the 
"localize" attribute is for the BEEP layer, BEEP implementers may not be 
aware that the application layer might want that information.  That being 
said, the BEEP implementation that I use most often appears to export the 
localization string.

There may be a layering argument that using the "localize" attribute isn't 
valid, but I don't feel particularly strongly about it.

>>>* the one BEEP example needs work.  For instance, the BEEP frame 
>>>isn't fully shown, and probably should be.
>>
>Examples?

Well, in particular, the existing example (in section 3.3.1) shows the frame 
header, but not the footer.  Not a big change, but:
   
   C: MSG 1 2 . 432 62\r\n
   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.0
   C: PRODID:-//someone's prodid
   C: CMD;ID=unique-per-cua-123;OPTIONS=10:GENERATE-UID
   C: END:VCALENDAR
   C: END\r\n

is more correct.

>>>I can spend a little be more time looking to see if there is 
>>>something else CAP needs to specify (like the message pattern).  I 
>>>think it probably does, but I expect 3080 has something specific 
>>>to say about it.

I will admit that in my initial response, I had utterly failed to read section 
12, which contains the meat of the BEEP information. (sorry about that :))

The draft does state what the messages patterns are and when you would use 
each pattern, which is good.  It was not clear to me if the draft is clear 
about the distinctions between Listener, Initiator, Client, and Server.  Some 
of the examples use the I:/L: pair, and some use the C:/S: pair.  Normally, 
when talking about BEEP, the distinction between I/L and C/S is only really 
apparent when talking about channel creation.  When talking about what the 
application does, generally you should stick to C/S, and specify when I or L 
can equal C or S (that is, when which side gets to act as the client or 
server).

To try and say this in a more accessible way: does CAP always equate the 
Listener with the Server and the Initiator with the Client?  If so, say so, 
if not, describe under what situations the Client/Server pair reverses, and 
warn folks that it will.  Having the Listener act as a client is normal for 
BEEP, but it might surprise non-BEEP experts.

Looking at section 12: 
  The initial message after authentication each direction MUST BE
   single "text/calendar" object containing a CAP "CAPABILITY" CMD and
   must not be part of a MIME multipart message.

Note that if CAP relies on the BEEP layer for authentication, then, 
technically, the authentication messages are not part of your profile.

-- 
David Blacka    <[email protected]> 
Sr. Engineer    VeriSign Applied Research