Subject: Re: [cuss] Encoding of protocol discriminator in the uui-isdn package

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 1 Mar 2012 17:06:54 +0100

Hi Keith,

Your own draft indeed already has wording about the protocol
discriminator, and also some wording where the payload in encoded:

11.  Coding requirements

   This document defines "isdn-uui" as a new value of the User-to-User
   "package" header field parameter.
   This document defines "isdn-uui" as a new value of the User-to-User
   "content" header field parameter.  A content value of "isdn-uui"
   indicates that the contents have a first octet that is a protocol
   discriminator (see table 4-26 of ITU-T Recommendation Q.931) [Q931]
   followed by uui-data that can be subject to a length limitation
   (before encoding or after decoding) that is generally 128 octets.

In many other places in the draft you speak about "UUI for the ISDN
package", "UUI", or "UUI data"
I could live with this, as this is sufficiently clear for me.

But I also have nothing against making the terminology within the draft
even more consistent.

Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext DRAGE, Keith (Keith)
Sent: Wednesday, February 29, 2012 12:33 PM
To: [email-masked]
Subject: [cuss] Encoding of protocol discriminator in the uui-isdn
package

In trying to sort our whether we have adequately specified the protocol
discriminator (I think we have), I notice that I have been using the
term "payload" and "UUI payload" in the package draft.

It looks to me like the mechanism draft uses the term "UUI data" to
refer to the material that goes in the ABNF construct 

"uui-data    = token / quoted-string"

I propose to replace the ISDN package terminology with "UUI data" to be
consistent assuming I see no objections.

It may be worth checking the mechanism draft to ensure this term is used
only in the context identified above in the mechanism draft (and
therefore does not encompass the header field parameters as well).

Responses?

Keith
_______________________________________________
cuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cuss