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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>