Re: terminationId syntax and semantics

Christian Groves <[email protected]>
Newsgroups gmane.ietf.megaco
Message-ID <[email protected]>
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 protected]
> https://www.ietf.org/mailman/listinfo/megaco
>  
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.