Subject: RE: [Megaco] Syntax of MID

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 26 Jul 2002 15:44:42 -0400

I would much rather have some text added stating explicitly that the mID is
only a logical identifier, then to alter the encodings.  Changing the ABNF
and ASN.1 encodings for this is an attempt to fix something that isn't
broken, whether the philosophy behind the existing encoding is flawed or
not.

Kevin

-----Original Message-----
From: Kaul, Bharat [mailto:[email-masked]]
Sent: Friday, July 26, 2002 2:51 PM
To: 'Aleksandr Ryabin'; [email-masked]
Cc: Boyle, Kevin [NCRTP:3R90:EXCH]; [email-masked]; Christian
Groves; Anand, Rashim
Subject: RE: [Megaco] Syntax of MID

Yes, I agree that ASN.1 seems an issue but I think most of the ASN.1
implementations today anyways have issue of  dealing with  implementations
sending MID as Octet Strings rather than the structure defined in ASN.1
(Taking off from our discussions on the mailing list as the basis)

I suppose that implies that anyone having ASN.1 parser today OR writing
ASN.1 parser going forward has to conceptually worry about following issues:

1) The packets received may has MID encoded as Octet String (as some
implmentations will assume based on the discussions on the mailing list that
MID is a logical string) or as a structure as defined in current ASN.1

2) Conceptually speaking, the parser output, however, in both cases must be
a logical identifier for protocol engines to deal with. How that happens is
an implementation issue.

So I already see interoperability issues here unless we impose that ASN.1
structures have to be followed irrespective of semantics of the element.
Then the parsers need to deal with point (2) only.

We have definitely CORRECTED our definition of MID from the earliest
understanding of it over last 2 years. In spirit of Section 11.5, I think
may be able to correct the syntax and help implementors by making their
lives simpler :). 

On a side note, do we have any estimate on how many ASN.1 implementations
exist ? ( I am aware of only 4).

- Bharat

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Friday, July 26, 2002 11:25 AM
To: Kaul, Bharat; [email-masked]
Cc: 'Kevin Boyle'; [email-masked]; Christian Groves; Anand, Rashim
Subject: RE: [Megaco] Syntax of MID

Hi,

It might (or might not depending on particular implementation) be true for 
text
encoding (I mean no parser changes), but definitely not true for ASN.1, thus
the change will basically break backward compatibility.

Although I do agree that for new versions we should fix any inconsistencies
found so far, the changes should not break anything. Making the change
to MId encoding (for new versions) will break backward compatibility with
older versions since the very first SC must be compatible across all the
versions for MG-MGC protocol version negotiation.

"11.3  Negotiation of protocol version" is very clear and strict about it:
...
    "When extending the protocol with new versions, the following rules
    should be followed:

    1) Existing protocol elements, i.e. procedures, parameters,
       descriptor, property, values, should not be changed unless a
       protocol error needs to be corrected or it becomes necessary to
       change the operation of the service that is being supported by
       the protocol."
...

Thanks.
         Aleks

At 01:42 PM 7/26/2002, Kaul, Bharat wrote:
>Kevin/Christian,
>
>  The new proposed syntax (part of which reproduced below) essentially has
>same characters that are currently allowed. So it should not affect any
>parser implementations. But it will definitely help reducing confusion.
>
> > mId = 1*( charsinMid )
> >
> > charsinMid = ALPHA / DIGIT / ":" / "@" / "." / "[" / "]" /
> >                      "-" / ">" / "<" / "{" / "}" / "_" / "*" / "/" / "$"
> >     ;    basically the same characters which can be present in domain
> > name/address/mtp address/device name
> >     ;    some other characters could also be allowed
>
>For people who are just picking up on megaco and have not necessarily
>followed discussions for last 2 years, it definitely will be helpful. The
>proposed changes seem to clear up the syntax rather than affect any
>implementation.
>
>- Bharat
>
>
>-----Original Message-----
>From: Kevin Boyle [mailto:[email-masked]]
>Sent: Friday, July 26, 2002 7:33 AM
>To: [email-masked]; Christian Groves
>Cc: Anand, Rashim; [email-masked]'
>Subject: RE: [Megaco] Syntax of MID
>
>
>I have to agree with Christian.  A change here is far more impacting than
>just removing confusion.  Everybody's parsers would have to be altered to
>accept the new syntax.  For established implementations, this may not be a
>trivial matter.
>
>While this change may reduce confusion (although even that isn't
>guaranteed), I don't see how that outweighs the negative impact that it
>would have on existing implementations.
>
>Kevin
>
>"Anand, Rashim" wrote:
> >
> > Hi,
> >    I am resending this mail to solicit comments.
> >
> > Some time back we had a thread on MID being just a logical identifier
>going
> > on in the mailing list.
> > 3015 Corr incorporates that concept (refer to section 8.3).
> >
> > Shouldn't the ABNF and ASN definitions be modified to reflect that?
> > Currently, MID is
> > defined to be a choice of -
> >
> > domain address / domain name / mtp address / device name
> >
> > I think that MID could be better defined as -
> >
> > mId = 1*( charsinMid )
> >
> > charsinMid = ALPHA / DIGIT / ":" / "@" / "." / "[" / "]" /
> >                      "-" / ">" / "<" / "{" / "}" / "_" / "*" / "/" / "$"
> >     ;    basically the same characters which can be present in domain
> > name/address/mtp address/device name
> >     ;    some other characters could also be allowed
> >
> > for ABNF and
> >
> >       mId         OCTET STRING (SIZE(...)),
> >
> > for ASN.
> >
> > Such a modification would better reflect the logical identification
>purpose
> > of mid. The current
> > definitions IMPLICITLY restrict MID to domain name / address etc. This
> > restriction is inconsistent
> > with the nature of MID.
> >
> > Based on above, serviceChangeMgcId and serviceChangeAddress (these are
> > currently of mId type) would have to be changed to something like -
> >
> > serviceChangeAddress = ServiceChangeAddressToken EQUAL
> >                        ( ServiceChangeAddress / portNumber )
> > serviceChangeMgcId   = MgcIdToken EQUAL ServiceChangeAddress
> >
> > ServiceChangeAddress = (( domainAddress / domainName )
> >                        [":" portNumber]) / mtpAddress / deviceName
> >
> > for ABNF and something like -
> >
> > serviceChangeMgcId  ServiceChangeAddress OPTIONAL,
> > in ServiceChangeParm with a comment - "the portNumber is not allowed
> > as a choice element in serviceChangeMgcId"
> > ( the serviceChangeAddress parameter in contrast to the
serviceChangeMgcId
> >   parameter can have just the portNumber )
> >
> > for ASN.
> >
> > Thank,
> > - Rashim
> >
> > _______________________________________________
> > 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
>
>_______________________________________________
>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: Christian Groves <[email-masked]>
Date: Mon, 29 Jul 2002 15:47:55 +1000

G'Day,

I come back to my original reply to this thread, "What is it you want to do,
that you can't with the current syntax?". If there isn't anything then its not
broken and we don't need to fix it.

MID is a fundamental part of any H.248/Megaco message and there's alot of
implementations with the current syntax. The interoperability and
incompatibilities problems that would be experienced if this change was made far
out weigh any benefits from clarification.

I would encourage people rather than patching individual issues with service
change to look at and contribute to Kevins work on coming up with a concise
annex to clairify Service Handling.

Reards, Christian

---

From: Christian Groves <[email-masked]>
Date: Mon, 29 Jul 2002 15:47:55 +1000

G'Day,

Reards, Christian