Subject: Re: Text PackageIDs

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 3 Feb 2000 09:07:01 -0500

Hold on a minute.  There were two subthreads to this thread, one of which
ended
with Christian agreeing with me that package names should not overlap
protocol tokens
while the other subthread had you worrying that we would run out of
abbreviations
if we restricted name spaces.

It is clear that the grammar allows us to have an entirely separate
namespace for
package names, as the slash is a delimiter which allows the parser to
disambiguate
a package name from a protocol token.  I don't like the idea of a package
named
KA, as in KeepActive so that you could say Signals=123{ka/ka{ka}}, but at
least
it's unambiguous. Could we not disallow a package name overlapping with
protocol
tokens?

In thinking through this, I wonder about overlap of termination names with
package names; the grammar could conceivably get confused, although I can't
spot a case
where a terminationID and a package item with the same name could be
confused by
other than the poor humans, as in
Modify=ka/ka{lc{ka/ka=0},Events=123{ka/ka{ka/ka,ka},Signals{ka/ka{ka/ka}}}
Looks like caca to me :)

Maybe this is another of those IETF things where the sender shouldn't do it,
but the receiver should allow it.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Wednesday, February 02, 2000 2:43 PM
> To: [email-masked]
> Subject: Text PackageIDs
>
>
> Section 12.1.1 contains the statement that the text encoding
> of a package
> identifier must not be a keyword in the base protocol.  This
> contradicts the
> conclusion of the thread "Megaco Reserved Names", 2-3 Nov
> 1999.  I will
> record this one as an "error".
>
> Tom Taylor
> Advisor -- Emerging Carrier IP Standards
> E-mail: [email-masked] (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961
>

---

From: Abdallah Rayhan <[email-masked]>
Date: Thu, 3 Feb 2000 10:39:46 -0500

This point what a source of confusion when packageNames were optional
but now they are not. At then we didn't want to confuse events and properties
with tokens, e.g., events and properties have local scope in the packages
they are defined in. I thought that this is a good strategy however
packageNames
were an issue. We decided in Wash that PackageNames can not be tokens
and they are not optional. As far as I am concerned, this resolved the issue.
If the text does not reflect this consensus, then it should.

TerminationIDs and packages, that is another issue. How come we didnt think
of it before ? Let us see! Terminations are variables, events are variables too

but have different scope since they are defined in packages. So, if
package/event
matches a termination name, it would be impractical to enforce a rule that
prevents this from happening. However, in a BCP draft we could report these
uses as discouraged.

Abdallah Rayhan