Subject: [Megaco] terminationId syntax and semantics

From: "Raphael Tryster" <[email-masked]>
Date: Sun, 28 Sep 2008 20:51:32 +0300

I think it is a safe bet that George W. Bush has spent almost his entire
presidency not understanding the rules by which which Megaco termination
identifiers are constructed.  I have been aware of the existence of
Megaco for about the same period, and don't understand them either.

TerminationID = "ROOT" / pathNAME / "$" / "*"

; Total length of pathNAME must not exceed 64 chars.
pathNAME = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" / "$" ) ["@"
pathDomainName ] 

; ABNF allows two or more consecutive "." although it is meaningless in
a path domain name.
pathDomainName = (ALPHA / DIGIT / "*" ) *63(ALPHA / DIGIT / "-" / "*" /
".")

NAME = ALPHA *63(ALPHA / DIGIT / "_" )

I have been happily building Megaco termination ids of the form
term1/term2/term3, like in MGCP, and hoping the above defintions would
go away.

Now, 3 of the possibilities for TerminationID are simple.  pathNAME is
the tricky one.  What would it mean if it starts with a "*"?  Wildcarded
first term?  But since NAME has to start with a letter, "*/5" would be
illegal, so "*" would have to be a prefix of the first term, not the
whole first term.  Then, once we have seen something like *A/5", we
could then follow it with something ridiculous, like "*A/5$$$_abcd////".
Why is it important that the first term start with a letter and not a
digit?  Why doesn't it matter for the other terms?

When should a terminationID include a pathDomainName and when not?  When
would one want to pepper a pathDomainName with "*"s?

What I am really looking for is to understand the reasoning that led to
defining the syntax as above.  What things was it designed to allow and
what was important to forbid?  Is there semantic meaning to the "/"
characters to delineate terms as units of wildcarding like in MGCP, or
is the stack expected to do the most general regular expression
processing with whatever legal string it gets, and the "/" has no
special meaning?  What abou the other special characters like "$".  Can
they be delimiters?  And so on.

I would be really grateful if someone can help me understand this before
I am older than either the president or the vice president of the U.S.A.

Raphael Tryster
**********************************************************************************************
IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the 
named recipient(s) only.
If you have received this email in error, please notify the system manager or the sender immediately and do 
not disclose the contents to anyone or make copies thereof.
*** eSafe scanned this email for viruses, vandals, and malicious content. ***
**********************************************************************************************

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

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Tue, 30 Sep 2008 11:49:21 +0200

I don't know the rationale behind that ABNF grammar (because I wasn't
involved in H.248 version 1).

Anyway, the profile concept is a perfect means to address such kind of
things (e.g. flexible syntax vs explicit semantic or not formal enough
ABNF) IMHO.
You may use the termination naming conventions in a profile to fix that
issue.
I'm not aware of any problems with profiled-defined termination names.

Of course, may email is not answering your questions.

[But I'm also not aware of any MG implementation, operating in the
NoProfile mode, and using an identity management function which tries to
generate unambiguous TerminationIDs solely on the basis of the Annex B
ABNF grammar rules.]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Raphael Tryster
> Sent: Sonntag, 28. September 2008 19:52
> To: megaco ietf
> Subject: [Megaco] terminationId syntax and semantics
> 
> I think it is a safe bet that George W. Bush has spent almost 
> his entire presidency not understanding the rules by which 
> which Megaco termination identifiers are constructed.  I have 
> been aware of the existence of Megaco for about the same 
> period, and don't understand them either.
> 
> ; ABNF allows two or more consecutive "." although it is 
> meaningless in a path domain name.
> I have been happily building Megaco termination ids of the 
> form term1/term2/term3, like in MGCP, and hoping the above 
> defintions would go away.
> 
> Now, 3 of the possibilities for TerminationID are simple.  
> pathNAME is the tricky one.  What would it mean if it starts 
> with a "*"?  Wildcarded first term?  But since NAME has to 
> start with a letter, "*/5" would be illegal, so "*" would 
> have to be a prefix of the first term, not the whole first 
> term.  Then, once we have seen something like *A/5", we could 
> then follow it with something ridiculous, like "*A/5$$$_abcd////".
> Why is it important that the first term start with a letter 
> and not a digit?  Why doesn't it matter for the other terms?
> 
> When should a terminationID include a pathDomainName and when 
> not?  When would one want to pepper a pathDomainName with "*"s?
> 
> What I am really looking for is to understand the reasoning 
> that led to defining the syntax as above.  What things was it 
> designed to allow and what was important to forbid?  Is there 
> semantic meaning to the "/"
> characters to delineate terms as units of wildcarding like in 
> MGCP, or is the stack expected to do the most general regular 
> expression processing with whatever legal string it gets, and 
> the "/" has no special meaning?  What abou the other special 
> characters like "$".  Can they be delimiters?  And so on.
> 
> I would be really grateful if someone can help me understand 
> this before I am older than either the president or the vice 
> president of the U.S.A.
> 
> Raphael Tryster
> IMPORTANT: The contents of this email and any attachments are 
> confidential. They are intended for the named recipient(s) only.
> If you have received this email in error, please notify the 
> system manager or the sender immediately and do not disclose 
> the contents to anyone or make copies thereof.