Subject: MEGACO: Impl. guide SHOCKER!

From: Troy Cauble <[email-masked]>
Date: Tue, 21 Nov 2000 11:55:10 -0500

Hello again,

Does section 6.48 of the Implementors Guide really say
that the text encoding that used to be this:

         Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 0
a=fmtp:PCMU VAD=X-NNVAD
        }

Is now this:

        Local {
763d30200a633d494e204950342024200a6d3d617564696f2024205254502f4156502030200a613d666d74703a50434d55205641443d582d4e4e5641440a
        }

!?!?!?!

Let's be reasonable.  There's no reason to make this unreadable.

SDP is UTF-8 conformant.  octetString is overkill for the SDP
encoding in localDescriptor and remoteDescriptor.

   localDescriptor      = LocalToken LBRKT octetString RBRKT

   remoteDescriptor     = RemoteToken LBRKT octetString RBRKT

It's these definititions that should be changed.  Don't make the
text encoding this much uglier because someone once wrote
"octetString" there.

As for the argument about escaping "{" and "}"; that's a form
of *encoding* just like this hex stuff.  So it shouldn't cause
any heartburn.  If you want to talk about non-conformance with
RFC 2327, let's talk about those dollar signs.

octetString has already been taken out of mtpAddress.  Please,
take it out of these descriptors too and get rid of it all together.

-troy

---

From: Christian Groves <[email-masked]>
Date: Wed, 22 Nov 2000 04:15:18 +1100

Hello Troy,

I think you have a GROSS misunderstanding of what was proposed. It was a
suggestion from Lucent have some conformity when you wanted to code a
Binary octet with the text encoding. If you wish to send a binary
encoded octet string then you should use the hex format proposed. If you
have SDP or text to send ofcourse you use text.

Christian

---

From: Troy Cauble <[email-masked]>
Date: Tue, 21 Nov 2000 12:37:24 -0500

Christian,

I'm happy to be wrong about the intent!

But if it's not referring to the "octetString" element
of the ABNF, what is it referring to?

From the problem description:
        "Sometimes it is desirable to transfer octet strings
         between MG and MGC."

WHEN??  This should be a clearly labled part of the ABNF
spec.

The solution describes how to do "hexidecimal octet coding"
but doesn't tell us where or when we would.

I jumped to the conclusion that you were referring to the ABNF
"octetString".  (It *was* mentioned in the problem description.)

Can I suggest that the ANBF element "octetString" be renamed to
avoid confusion?

-troy

---

From: Christian Groves <[email-masked]>
Date: Wed, 22 Nov 2000 05:18:39 +1100

G'Day Troy,

OK maybe binary octer strings should have been mentioned. The section
was added as a guideline for the future and didn't intend to change any
current definitions. I'll let other people reply on renaming OCTET
STRING in ABNF.

Christian