Subject: Re: [Megaco] terminationId syntax and semantics

From: Christian Groves <[email-masked]>
Date: Mon, 06 Oct 2008 11:22:07 +1100

Hello Raphael,

I think you will be disappointed on your quest to understand the hidden 
deeper meaning behind this. Termination IDs were meant to be a hierarchy 
of names. You can see the examples in Annex A (binary encoding) on the 
possibilities. I think the disconnect came that when defining the text 
encoding, people were thinking more of a URI style format for 
termination IDs.  The URI syntax was translated to Megaco ABNF and the 
problem with "NAME" having to be an ALPHA was introduced. This also had 
a side effect that text package names have to start with a letter which 
caused some problem for 3GPP.

As for the usage of pathDomainName I haven't seen any proposed usage for 
this in any standards document.
For the usage of "*"s maybe a MGC wants to audit a certain heirarchy level?

I think the best advice is to try to work in with terminationID schemes 
already defined in profiles. At least Tispan and 3GPP share a reasonably 
common scheme.

Regards, Christian

PS: Soon George W will be in retirement and will be able to devote his 
entire time to this issue....

Raphael Tryster wrote:
> 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
>  
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>   
_______________________________________________
Megaco mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/megaco