Subject: RE: [Megaco] RE: Deleting DigitMap from a Termination

From: Aleksandr Ryabin <[email-masked]>
Date: Mon, 03 Jun 2002 13:53:15 -0400

Hi folks,

         This is a resend. Does anybody have an opinion on this?
I'm sorry, if this is something that have already been "chewed on",
in which case please point/forward me to right direction/place.

Thanks
         Aleks

At 08:06 PM 5/30/2002, Aleksandr Ryabin wrote:
>Hi,
>
>         I know its been a while since this email, but I was going through
>digit map declarations in the 3015corr draft and noticed that ABNF does not
>seem to permit empty digitMapValue using empty braces:
>
>digitMapDescriptor = DigitMapToken EQUAL ( ( LBRKT digitMapValue RBRKT ) /
>         (digitMapName [ LBRKT digitMapValue RBRKT ]) )
>
>That is for the example below to be correct it should be changed to:
>
>digitMapDescriptor = DigitMapToken EQUAL ( ( LBRKT [ digitMapValue ] RBRKT ) /
>         (digitMapName [ LBRKT [ digitMapValue ] RBRKT ]) )
>
>or the example should be modified as follow to omit braces:
>
>Transaction = 1 {
>    Context = - {
>       Modify = TermA {
>          DigitMap = Dmap1 ; empty value for a name
>       }
>    }
>}
>
>Which one would be right? Or am I reading it all wrong?
>
>Also I'm trying to understand a usage of nameless digit maps defined by 
>DigitMapDescriptor.
>Ether I'm missing something obvious (my apologies then), or it does not 
>seem to be possible
>to reference in EventDM such previously defined nameless digit map using 
>ether ASN.1, or
>ABNF. It also seems to be impossible with current ABNF syntax to delete 
>nameless digit map.
>Can someone clarify this for me please?
>
>Thanks
>         Aleks
>
>At 06:32 PM 4/10/2002, Tom-PT Taylor wrote:
>>You are correct.  See section 7.1.14.1.
>>
>>-----Original Message-----
>>From: Sudhir Kumar Appana [mailto:[email-masked]]
>>Sent: Wednesday, April 10, 2002 2:15 PM
>>To: [email-masked]
>>Cc: Sudhir (E-mail)
>>Subject: [Megaco] RE: Deleting DigitMap from a Termination
>>
>>
>>Tom,
>>Can you please respond to this mail.
>>Thanks,
>>Sudhir
>>
>>
>>-----Original Message-----
>>From: Sudhir Kumar Appana [mailto:[email-masked]]
>>Sent: Wednesday, April 10, 2002 5:13 PM
>>To: [email-masked]
>>Cc: Sudhir (E-mail)
>>Subject: Deleting DigitMap from a Termination
>>
>>
>>Hi,
>>
>>Is MGC can delete the DigitMap that is already defined using the
>>following packet:
>>
>>Transaction = 1 {
>>    Context = - {
>>       Modify = TermA {
>>          DigitMap = Dmap1 { }  ; empty value for a name
>>       }
>>    }
>>}
>>
>>First of all, MGC can Modify DigitMap on a Termination which is in NULL
>>Context.
>>
>>Thanks,
>>Sudhir
>>
>>
>>_______________________________________________
>>Megaco mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>_______________________________________________
>>Megaco mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/megaco
>
>
>_______________________________________________
>Megaco mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/megaco

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

---

From: Aleksandr Ryabin <[email-masked]>
Date: Mon, 03 Jun 2002 13:53:15 -0400

Hi folks,

Thanks
         Aleks

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 03 Jun 2002 14:18:54 -0400

I am not sure one actually needs to clear a DigitMap.  If no events are 
associated with it, it will have no affect.  Are you concerned about 
saving storage space, by notifying the MG that a named digitMap will not 
be used in the future?  

Unnamed digitMaps are only used in the event that includes them.  They 
cannot be used by other events.  To you them in more than one event you 
must use the named form.  And again you need not delete an unnamed 
digitmap.  When the event that defined it ceases to exit so does the 
need for the digitMap.

Aleksandr Ryabin wrote:

>> Also I'm trying to understand a usage of nameless digit maps defined 
>> by DigitMapDescriptor.
>> Ether I'm missing something obvious (my apologies then), or it does 
>> not seem to be possible
>> to reference in EventDM such previously defined nameless digit map 
>> using ether ASN.1, or
>> ABNF. It also seems to be impossible with current ABNF syntax to 
>> delete nameless digit map.

-- 
-------------------------------------------------------
Terry L Anderson, DMTS                   [email-masked]
Lucent Technologies /INS/ Voice over IP Access Networks
Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
Voice:908 582-7013  FAX:908 582-6226   Org:18E75000000
http://its.lucent.com/~tla  (Lucent internal)
http://www.gti.net/tla
-------------------------------------------------------

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 03 Jun 2002 14:18:54 -0400

---

From: Aleksandr Ryabin <[email-masked]>
Date: Mon, 03 Jun 2002 15:26:40 -0400

Hi Terry,
         Please see below inline.

>saving storage space, by notifying the MG that a named digitMap will not 

Yes, precisely.

Although it does not really matter why MGC wants to clear it.
The reason I asked is that given example seems to contradict ABNF syntax
and I'd like to clarify which one is correct (or should be correct). Opinions?

>digitmap.  When the event that defined it ceases to exit so does the need 
>for the digitMap.

If I understand you correctly then what you are saying is unnamed digit map 
can
only be defined in eventDM. But I'm asking about defining unnamed digit map in
digitMapDescriptor. The reason I ask is: digitMapName defined as optional in
digitMapDescriptor, thus MGC can possibly define unnamed digit map. But then
how can MGC reference such unnamed digit map later, or even in the same
command in eventDM? If there is no way, then shouldn't we remove this ambiguity
and make digitMapName mandatory, e.g:

ABNF: digitMapDescriptor = DigitMapToken EQUAL digitMapName [ LBRKT 
digitMapValue RBRKT ]
ASN.1: remove OPTIONAL modifier for digitMapName in digitMapDescriptor.

Thanks
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Mon, 03 Jun 2002 15:26:40 -0400

Hi Terry,
         Please see below inline.

Yes, precisely.

Thanks
         Aleks

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 03 Jun 2002 17:12:54 -0400

I'm sorry I should have checked more carefully before replying.  See below

Aleksandr Ryabin wrote:

>> I am not sure one actually needs to clear a DigitMap.  If no events 
>> are associated with it, it will have no affect.  Are you concerned 
>> about saving storage space, by notifying the MG that a named digitMap 
>> will not be used in the future?
>
>
> Yes, precisely.
>

Actually deleting a named digitmap is described in 7.1.14.1.  And is 
done by providing "an empty value".  I believe that this is done by
    DigitMap = someMapName,
That is WITHOUT braces.  This is allowed by the syntax and is what you 
suggested as one alternative below.  You suggest this as a correction to 
an example.  Where does the incorrect example appear other than the mail 
from Sudhir?

>> Unnamed digitMaps are only used in the event that includes them.  
>> They cannot be used by other events.  To you them in more than one 
>> event you must use the named form.  And again you need not delete an 
>> unnamed digitmap.  When the event that defined it ceases to exit so 
>> does the need for the digitMap.
>
>
> If I understand you correctly then what you are saying is unnamed 
> digit map can

Digitmaps (digitMapValue) can be used either in a digitMapDescriptor or 
as I was suggesting in an eventDM.  In either case an associated 
digitMapName is optional.  I suggested a use for it being optional in 
eventDM but you are questioning its use in digitMapDescriptor.  I agree 
that it is probably useless when the Descriptor is sent as part of 
ammParameter (to define a digitmap) but the digitMapDescriptor is also 
used in auditReturnParameter.  I think the nameless form is still needed 
there to return an unnamed digitmap (defined in an eventDM) in response 
to an audit.

>>>> Also I'm trying to understand a usage of nameless digit maps 
>>>> defined by DigitMapDescriptor.

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 03 Jun 2002 17:12:54 -0400

---

From: Aleksandr Ryabin <[email-masked]>
Date: Mon, 03 Jun 2002 18:01:19 -0400

Hi,
         Please see below inline.

Also current ASN.1 definition for digitMapDescriptor defines both fields as 
OPTIONAL:

    DigitMapDescriptor ::= SEQUENCE
    {
       digitMapName   DigitMapName   OPTIONAL,
       digitMapValue  DigitMapValue  OPTIONAL
    }

As a result when both fields are missing it is equivalent to ABNF "DigitMap 
= " which is
not allowed, thus I believe ASN.1 definition of DigitMapDescriptor should 
be changed to:

    DigitMapDescriptor ::= CHOICE
    {
       digitMapValue      DigitMapValue,
       digitMapWithName   DigitMapWithName
    }

    DigitMapWithName ::= SEQUENCE
    {
       digitMapName   DigitMapName,
       digitMapValue  DigitMapValue
    }

At 05:12 PM 6/3/2002, Terry L Anderson wrote:
>Actually deleting a named digitmap is described in 7.1.14.1.  And is done 
>by providing "an empty value".  I believe that this is done by
>    DigitMap = someMapName,

Thanks, that is it, just the mail.

I'd like to suggest to modify 7.1.14.1 comment to say something like 
"providing DigitMap name only"
rather then "an empty value" as the ABNF "digitMapValue" definition itself 
does not include braces,
so technically "empty value" might be interpreted as { } which exactly the 
reason for created confusion.

>>>They cannot be used by other events.  To you them in more than one event 
>>>you must use the named form.  And again you need not delete an unnamed 
>>If I understand you correctly then what you are saying is unnamed digit 
>>map can
>Digitmaps (digitMapValue) can be used either in a digitMapDescriptor or as 
>I was suggesting in an eventDM.  In either case an associated digitMapName 
>is optional.  I suggested a use for it being optional in eventDM but you 
>are questioning its use in digitMapDescriptor.  I agree that it is 
>probably useless when the Descriptor is sent as part of ammParameter (to 
>define a digitmap) but the digitMapDescriptor is also used in 
>auditReturnParameter.  I think the nameless form is still needed there to 
>return an unnamed digitmap (defined in an eventDM) in response to an audit.

That what I missed, thank you.
Although, again to avoid confusion, it would be nice to have a comment 
which clarifies
that nameless digitMapDescriptor form should be used only for 
auditReturnParameter.

Thanks
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Mon, 03 Jun 2002 18:01:19 -0400

Hi,
         Please see below inline.

Thanks
         Aleks

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 03 Jun 2002 18:32:44 -0400

Aleksandr Ryabin wrote:

> Hi,
>         Please see below inline.
>
> Also current ASN.1 definition for digitMapDescriptor defines both 
> fields as OPTIONAL:
>
> As a result when both fields are missing it is equivalent to ABNF 
> "DigitMap = " which is
> not allowed, thus I believe ASN.1 definition of DigitMapDescriptor 
> should be changed to:
>

I think that we need three of the four cases syntactically allowed,
1. name without a value (to clear the map)
2. value without a name (as discussed below for the text case, to use in 
an audit response)
3. name and value
As you point out neither name or value is an error.  While it is 
possible to enforce this with more complex ASN.1 the protocol has opted 
in many places to depend on the rationality of the user and comments to 
imply such restrictions.  While we could add a comment:
    ; at least one of the options must be present
it seems rather obvious, since omitting both has no useful meaning.

>>>> about saving storage space, by notifying the MG that a named 
>>>> digitMap will not be used in the future?
>>>
>>>
>>>
>>> Yes, precisely.
>>>
>> That is WITHOUT braces.  This is allowed by the syntax and is what 
>> you suggested as one alternative below.  You suggest this as a 
>> correction to an example.  Where does the incorrect example appear 
>> other than the mail from Sudhir?
>
>
> rather then "an empty value" as the ABNF "digitMapValue" definition 
> itself does not include braces,
> so technically "empty value" might be interpreted as { } which exactly 
> the reason for created confusion.

"empty value" or the equivalent has, unfortunately, different syntactic 
forms in different descriptors in the text representation.  Empty braces 
is sometimes used.  A token with nothing following it is used elsewhere. 
 The differences were in some cases deliberate to avoid parsing problems 
or particularly odd looking formations and at other times may have been 
accidental.  There have been suggestions to use {} consistently but this 
also causes problems such as in the Event case where it forces one to 
specify a responseId for an empty event list (although Troy has pointed 
out a parsing problem that may force us to do it there).  In any case, 
it seems unlikely that we will want to change the form where it does not 
actually cause an problem, thereby breaking compatibility with existing 
parsers.  So I think we will continue to have a couple of different 
forms for "empty".

>>>> event you must use the named form.  And again you need not delete 
>>>> an unnamed digitmap.  When the event that defined it ceases to exit 
>>>> so does the need for the digitMap.
>>>
>>>
>>>
>> Digitmaps (digitMapValue) can be used either in a digitMapDescriptor 
>> or as I was suggesting in an eventDM.  In either case an associated 
>> eventDM but you are questioning its use in digitMapDescriptor.  I 
>> agree that it is probably useless when the Descriptor is sent as part 
>> of ammParameter (to define a digitmap) but the digitMapDescriptor is 
>> also used in auditReturnParameter.  I think the nameless form is 
>> still needed there to return an unnamed digitmap (defined in an 
>> eventDM) in response to an audit.
>
>
>>>>>> Ether I'm missing something obvious (my apologies then), or it 
>>>>>> does not seem to be possible
>>>>>> to reference in EventDM such previously defined nameless digit 
>>>>>> map using ether ASN.1, or
>>>> http://its.lucent.com/~tla <http://its.lucent.com/%7Etla%A0> 
>>>> (Lucent internal)
>>>> http://www.gti.net/tla
>> http://its.lucent.com/~tla <http://its.lucent.com/%7Etla%A0> (Lucent 
>> internal)
>> http://www.gti.net/tla

-- 

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:732.949.5628   Fax:732.949.7016
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 03 Jun 2002 18:32:44 -0400

--

---

From: Aleksandr Ryabin <[email-masked]>
Date: Mon, 03 Jun 2002 18:53:49 -0400

Understood, comment will do.

If there are no objections could the editors of current drafts (3015corr 
and v2)
please add the comment to ASN.1 definition of DigitMapDescriptor as
indicated by Terry below?

Thanks
         Aleks

At 06:32 PM 6/3/2002, Terry L Anderson wrote:

>Aleksandr Ryabin wrote:
>
>>Hi,
>>         Please see below inline.
>>
>>Also current ASN.1 definition for digitMapDescriptor defines both fields 
>>as OPTIONAL:
>>
>As you point out neither name or value is an error.  While it is possible 
>to enforce this with more complex ASN.1 the protocol has opted in many 
>places to depend on the rationality of the user and comments to imply such 
>restrictions.  While we could add a comment:
>The differences were in some cases deliberate to avoid parsing problems or 
>particularly odd looking formations and at other times may have been 
>out a parsing problem that may force us to do it there).  In any case, it 
>seems unlikely that we will want to change the form where it does not 
>parsers.  So I think we will continue to have a couple of different forms 
>for "empty".
>
>>
>>>>>cannot be used by other events.  To you them in more than one event

---

From: Aleksandr Ryabin <[email-masked]>
Date: Mon, 03 Jun 2002 18:53:49 -0400

Thanks
         Aleks

---

From: Christian Groves <[email-masked]>
Date: Tue, 04 Jun 2002 17:15:41 +1000

G'Day,

I think the use is described in the procedures and as Terry has mentioned the
ABNF does not enforce such constructs rather leaving it to people to read the
procedures. As v1 Amendment 1 and H.248v2 are already approved the editor's
can't add anything to the documents. A note could be added in the IG but I doubt
see that its fixing any error in the protocol.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Tue, 04 Jun 2002 17:15:41 +1000

G'Day,

Regards, Christian