Re: Channel response serialization

Would it be possible to use this beep extension mechanism
to negotiate the ability to send one-way messages (messages
that do not have any replies)?

Greg  [new to beep...]

> 
> > OK. I don't want to rat-hole on this so: do I understand correctly that
> you
> > are proposing to amend the RFC to make serialization on a channel
> optional?
> 
> no. what i'm proposing is that we use beep's extension mechanism (called
> "features") and write a new document that talks defines a feature that
> removes the same-order property. rfc3080 doesn't change. presumably a new
> rfc gets published that describes how something implementing rfc3080 can
> also say that it does the new thing too.
> 
> /mtr
> 
> 
> _______________________________________________
> BEEPwg mailing list
> BEEPwg <at> lists.beepcore.org
> http://lists.beepcore.org/mailman/listinfo/beepwg
> 

Re: Channel response serialization

Greg Weber <gdweber <at> cisco.com> writes:

> Would it be possible to use this beep extension mechanism
> to negotiate the ability to send one-way messages (messages
> that do not have any replies)?

Certainly.  Is there some situation when this would be significantly
better than MSG/NUL exchanges for you?

--Jered

Re: Channel response serialization

> 
> Greg Weber <gdweber <at> cisco.com> writes:
> 
> > Would it be possible to use this beep extension mechanism
> > to negotiate the ability to send one-way messages (messages
> > that do not have any replies)?
> 
> Certainly.  Is there some situation when this would be significantly
> better than MSG/NUL exchanges for you?

I was thinking of performance/traffic.  Lack of support for
one-way messages despite reliable transport seems to be often 
cited in support of work similar to beep, e.g.
  draft-hessing-p2p-messaging-00.txt.

Greg

> 
> --Jered
> 
> 

Re: Channel response serialization

On Friday, Aug 2, 2002, at 13:57 US/Pacific, Greg Weber wrote:
>
> I was thinking of performance/traffic.  Lack of support for
> one-way messages despite reliable transport seems to be often
> cited in support of work similar to beep, e.g.
>   draft-hessing-p2p-messaging-00.txt.

Here's my hipshot response to concerns about network overhead in BEEP: 
we want tuning profiles for compression protocols.  I can imagine a 
compression protocol that squeezes a lot of bytes out of the BEEP 
header and trailer, as well as shaving some off the encodings of the 
management profile messages.

Since I don't have a deep compelling need to see such protocols 
deployed, I'm not agitating loudly to contribute to their drafting.  
You want to do that?  Go for it.  I will wait for you here.

--james

About beep output and input stream

Re: About beep output and input stream

Liberty Alliance / SAML and BEEP

Is anyone looking into the use of the Liberty Alliance / SAML work with
BEEP sessions?

4K Limit to Profile element length

Forgive me for a very simple question:
RFC3080 says at "2.3.1.2 The Start Message" that: "the content of the
"profile" element, if present, must be no longer than 4K octets in
length".
	The question is: If the content of the profile element is
encoded (Base64), then does the length restriction apply to the encoded
form of the content or to the result after decoding? i.e. if encoding
causes the size of the data to grow, does that matter?

		bob wyman

Re: 4K Limit to Profile element length

I took it to mean 4k after encoding because that coincides with the default
window size.

--Huston

----- Original Message -----
From: "Bob Wyman" <bobwyman <at> firstrain.com>
To: <beepwg <at> lists.beepcore.org>
Sent: Wednesday, August 14, 2002 9:23 AM
Subject: [BEEPwg] 4K Limit to Profile element length

> Forgive me for a very simple question:
> RFC3080 says at "2.3.1.2 The Start Message" that: "the content of the
> "profile" element, if present, must be no longer than 4K octets in
> length".
> The question is: If the content of the profile element is
> encoded (Base64), then does the length restriction apply to the encoded
> form of the content or to the result after decoding? i.e. if encoding
> causes the size of the data to grow, does that matter?
>
> bob wyman
> _______________________________________________
> BEEPwg mailing list
> BEEPwg <at> lists.beepcore.org
> http://lists.beepcore.org/mailman/listinfo/beepwg
>

Re: 4K Limit to Profile element length

Huston wrote:
> I took it to mean 4k after encoding because that coincides with the default
> window size.

Except that you can have multiple profile elements in a start message, and
you have extra overhead in the start messages too, so a limit of 4K here
doesn't mean it fits in the default window size.

--

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   ** http://images.fbrtech.com/dnew/ **

Humility? Why would I need to show some humility?