Subject: Re: Wildcard in ContextId

From: Kapil Nayar <[email-masked]>
Date: Thu, 1 Feb 2001 20:26:48 +0530

Hi Tom

....probably a mention in IG would be helpful ?

-Kapil Nayar
Hughes Software Systems

Tom Taylor <[email-masked]> on 02/01/2001 07:57:48 PM

Please respond to "Tom-PT Taylor" <[email-masked]>

To:   Kapil Nayar/HSS@HSS
cc:   [email-masked]

Subject:  Re: Wildcard in ContextId

I think Chuong's inference is right.  An ANY placeholder as you propose
it is an attractive v2 option.  In the meantime, the workaround is that
the MGC has to be precise in its commands, giving the exact context for
each termination to be subtracted.

Kapil Nayar wrote:
>
> Hi
>
> Taking a clue from Chuong's example,
> Context = * { Subtract = a/b/c/t123* } or Context = * { Subtract = * }
> may result in a large number of command replies with error descriptors.
>
> We may all agree that the reasonable way to handle this is to resolve the
> contexts and then resolve the terminations in those contexts, which is
> against the assumption that context ids are resolved based upon the first
> command in the action.
>
> Observing this thread of discussion, I wondered if we have ever thought
> of a wildcarded option ANY(?) for context id in the protocol
> (in addition to "ALL"(*), "CHOOSE"($) and "NULL"(-) existing in the protocol)
> (ANY may refer to any existing context including NULL but doesn't specifically
> refer to any one or all context ids).
>
> The ANY context id :
> -    Cannot be partially wildcarded.
> -    May be actively used for Subtract command with wildcarded termination id.
> -    in Audit Value (termination wild carded) - audit of all matching
>      terminations (even in NULL context).
> Since, ANY would resolve to any (all including NULL) context ids, its usage
> can be restricted to avoid any further confusion.
>
> Revisiting the examples sighted in this thread:
>
> Context = ? { Subtract = T2, Subtract = T1 }
> Subtract T2 and T1 from there respective contexts without any need to return
> error
> descriptor from the first or the second command execution.
>
> Context = ? {Subtract = a/b/c/t123*}
> Above can also be handled the same way.
>
> Context = ? { W-Audit = * { ... }, Subtract = T1 }
> This would return the audit results for all the terminations and successfully
> subtract
> the termination T1 from its context without returning error descriptor.
>
> Any comments ?
>
> -Kapil Nayar
> Hughes Software Systems
>
> Chuong Nguyen <[email-masked]> on 02/01/2001 05:20:19 AM
>
> Please respond to Chuong Nguyen <[email-masked]>
>
> To:   [email-masked]
> cc:    (bcc: Kapil Nayar/HSS)
>
> Subject:  Re: Wildcard in ContextId
>
> Just to make everything really clear.
> The second command failed because the first command passed thus locking the
> contextId
> (said at 100).  The second command is executed based on this contextId=100 and
> not
> the contextId=ALL.  Since contextId 100 did not contain the second
termination,
> the second
> command failed.
>
> Thus leading to the conclusion that ContextId is always tied to first command.
>
> Does all these  discussions break the following
> Context = * {Subtract = a/b/c/t123*} since t1234 might be in a different
context
> than t12345?
>
> because isn't the above a condensed version of the following
> Context = *{Subtract = a/b/c/t1231, Subtract = a/b/c/t1232 .....,Subtract =
> a/b/c/t123n}
> which will return error after the second Subtract if a/b/c/t1232 is not in the
> same
> context as a/b/c/t1231 based on the ongoing discussion.
>
> Chuong
>
> Tom Taylor wrote:
>
> > You return the contextID which worked for the first command.  My best guess
at
> the error for the second command is 433
> > TerminationID is already in a context, as the least misleading possibility.
> This very clearly a case where command order matters
> > and is respected, since the first command succeeds and the second fails as a
> result.
> >
> > On Wed, 31 Jan 2001 12:50:31 -0600, Chuong Nguyen
> <[email-masked]> wrote:
> >
> > >I was always going to first command in the action and look at the
termination
> > >
> > >and then decide if contextId has any revelence.
> > >
> > >Tom by you saying yes - does this somehow break the rules that commands are
> > >processed
> > >in order?
> > >The first command would pass but the second one would fail so what does the
> > >MG returns for Context Id?
> > >
> > >Chuong
> > >
> > >
> > >Sachin Mittal wrote:
> > >
> > >> That means
> > >> "the context parsing can't be done
> > >> independently of the command parsing"
> > >> as the MG has to check whether the first command terminations
> > >> give the same set of Context IDs as the subsequent command
> > >> terminations.
> > >>
> > >> Sachin
> > >>
> > >> Tom-PT Taylor <[email-masked]> on 01/31/2001 11:27:12 PM
> > >>
> > >> Please respond to Tom-PT Taylor <[email-masked]>
> > >>
> > >> To:   [email-masked]
> > >> cc:    (bcc: Sachin Mittal/HSS)
> > >>
> > >> Subject:  Re: Wildcard in ContextId
> > >>
> > >> Yes, I would say so.
> > >>
> > >> > -----Original Message-----
> > >> > From: [email-masked] [mailto:[email-masked]]
> > >> > Sent: Wednesday, January 31, 2001 12:31 PM
> > >> > To: Taylor, Tom-PT [NORSE:B901:EXCH]
> > >> > Cc: [email-masked]
> > >> > Subject: Re: Wildcard in ContextId
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > If we both are correct, then it should be ok for an MG to
> > >> > give error descriptor
> > >> > on seeing
> > >> > the following
> > >> > >> >     Context = * {
> > >> > >> >         Subtract = T2,
> > >> > >> >         Subtract = T1
> > >> > >> >     }
> > >> > if both T1 and T2 are in different contexts.
> > >> > Sachin
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > Tom Taylor <[email-masked]> on 01/31/2001 10:13:00 PM
> > >> >
> > >> > Please respond to Tom Taylor <[email-masked]>
> > >> >
> > >> > To:   [email-masked]
> > >> > cc:    (bcc: Sachin Mittal/HSS)
> > >> >
> > >> > Subject:  Re: Wildcard in ContextId
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > The fact is that when the MGC specifies a particular
> > >> > terminationID in a command
> > >> > other than ADD, the contextID is relevant only
> > >> > as a consistency check.  Despite this, I think Brian is right
> > >> > and you are right
> > >> > in your derived conclusion: enclosure of two commands
> > >> > within the same action implies that they both relate to the
> > >> > same context.
> > >> >
> > >> > On Wed, 31 Jan 2001 20:26:52 +0530, Sachin Mittal
> > >> > <[email-masked]> wrote:
> > >> >
> > >> > >If the example is broken into two commands then it means
> > >> > that more than one
> > >> > >command
> > >> > >in an action with Context ID = * can only be used when it is
> > >> > known by the
> > >> > sender
> > >> > >that the matching of all such commands in this action will
> > >> > result into the same
> > >> > >set of
> > >> > >Contexts. This then is a limitiation, and implies that in
> > >> > most cases of Context
> > >> > >ID = *
> > >> > >not more than one command will be present.
> > >> > >
> > >> > >
> > >> > >Sachin
> > >> > >
> > >> > >"Rosen, Brian" <[email-masked]> on 01/19/2001 06:28:03 PM
> > >> > >
> > >> > >Please respond to "Rosen, Brian" <[email-masked]>
> > >> > >
> > >> > >To:   [email-masked]
> > >> > >cc:    (bcc: Sachin Mittal/HSS)
> > >> > >
> > >> > >Subject:  Re: Wildcard in ContextId
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >I think this makes implementations more difficult for no significant
> > >> > >gain.  What you would need to do is to do all the matching
> > >> > for all the
> > >> > >commands,
> > >> > >rather than process one command at a time.  I'm already
> > >> > reluctant to require
> > >> > >that context=* is evaluated on the first command, since the
> > >> > basic mechanism
> > >> > >was supposed to allow the context parsing to be done
> > >> > independently of the
> > >> > >command parsing.  Your example would be better expressed as
> > >> > two actions with
> > >> > >one command each rather than one action with two commands.
> > >> > >
> > >> > >Brian
> > >> > >
> > >> > >> -----Original Message-----
> > >> > >> From: Sachin Mittal [mailto:[email-masked]]
> > >> > >> Sent: Thursday, January 18, 2001 11:54 PM
> > >> > >> To: [email-masked]
> > >> > >> Subject: Re: Wildcard in ContextId
> > >> > >>
> > >> > >>
> > >> > >> If we remove the complication of W- from the example
> > >> > >> >     Context = * {
> > >> > >> >         W-Audit = * { ... }
> > >> > >> >         Subtract = T1
> > >> > >> >     }
> > >> > >> and change it to
> > >> > >> >     Context = * {
> > >> > >> >         Subtract = T2,
> > >> > >> >         Subtract = T1
> > >> > >> >     }
> > >> > >> where T2 is in ContextID=2 and T1 is in ContextID=1 (say)
> > >> > >> the choice of response #2 is incorrect. It doesn't make sense
> > >> > >> to tell MGC that in Context =2 the subtract of T1 has failed.
> > >> > >> The general
> > >> > >> idea "Context=* matches Contexts with
> > >> > >> terminationIDs that match the FIRST action terminationId"
> > >> > >> becomes invalid for this very common case where MGC doesn't
> > >> > >> know the Contexts
> > >> > >> in which T1 , T2 exists but wants to subtract them wherever
> > >> > >> they exist.
> > >> > >>
> > >> > >> Sachin
> > >> > >> Hughes Software Systems
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >> "Rosen, Brian" <[email-masked]> on 01/17/2001 12:11:37 AM
> > >> > >>
> > >> > >> Please respond to "Rosen, Brian" <[email-masked]>
> > >> > >>
> > >> > >> To:   [email-masked]
> > >> > >> cc:    (bcc: Sachin Mittal/HSS)
> > >> > >>
> > >> > >> Subject:  Re: Wildcard in ContextId
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >> I think Context=* gets you multiple replies.
> > >> > >> I think processing of Context=* occurs before consideration
> > >> > >> of terminationIds given the current text.
> > >> > >>
> > >> > >> I like your example.  I'd choose #2 as the correct response.
> > >> > >>
> > >> > >> We could consider trying to make it better, slightly,
> > >> > >> by specifying that Context=* matches Contexts with
> > >> > >> terminationIDs that match the FIRST action terminationId.
> > >> > >> Then you clearly would get errors in your example, but
> > >> > >> the common case would work better.
> > >> > >>
> > >> > >> Brian
> > >> > >>
> > >> > >> > -----Original Message-----
> > >> > >> > From: Mike Broome [mailto:[email-masked]]
> > >> > >> > Sent: Tuesday, January 16, 2001 12:47 PM
> > >> > >> > To: Rosen, Brian
> > >> > >> > Cc: [email-masked]
> > >> > >> > Subject: Re: Wildcard in ContextId
> > >> > >> >
> > >> > >> >
> > >> > >> > I'm not sure what the syntax "Context-W=*" means.
> > >> > (That's might be
> > >> > >> > your point:  it is not valid syntax.)
> > >> > >> >
> > >> > >> > When using Context=* and W- on a command, should the reply be
> > >> > >> > one action
> > >> > >> > or multiple actions?  Section 7.3 of the Implementors'
> > >> > Guide defines
> > >> > >> > this scenario as returning one action with Context=* in the
> > >> > >> reply.  Is
> > >> > >> > this still the case?  Or are you saying that Context=*
> > >> > in a request
> > >> > >> > should always be expanded into multiple replies?
> > >> > >> >
> > >> > >> > What happens for a more complicated action like the following:
> > >> > >> >
> > >> > >> >     Context = * {
> > >> > >> >         W-Audit = * { ... }
> > >> > >> >         Subtract = T1
> > >> > >> >     }
> > >> > >> >
> > >> > >> > This is a somewhat ambiguous command for an MGC to send, but
> > >> > >> > how should
> > >> > >> > it be handled?  Section 7.3 of the Implementors' Guide
> > >> > only has an
> > >> > >> > example for a single W- command in an action.  I see three
> > >> > >> > possibilities
> > >> > >> > here:
> > >> > >> >
> > >> > >> > 1. Send back an error because the termination specifier
> > >> > >> doesn't match
> > >> > >> > between the two commands (ALL and specific).
> > >> > >> >
> > >> > >> > 2. Expand the Context=* and send back multiple replies,
> > >> > >> with an error
> > >> > >> > descriptor for the Subtract command in all the replies except the
> > >> > >> > Context that contains T1.
> > >> > >> >
> > >> > >> > 3. Internally, split the action into multiple actions with
> > >> > >> > the commands
> > >> > >> > grouped based on the termination specifier and W-.  For the
> > >> > >> example I
> > >> > >> > gave, we'd end up with two actions:
> > >> > >> >
> > >> > >> >     Context = * {
> > >> > >> >         W-Audit = * { ... }
> > >> > >> >     }
> > >> > >> >
> > >> > >> >     Context = * {
> > >> > >> >         Subtract = T1
> > >> > >> >     }
> > >> > >> >
> > >> > >> > Any comments?
> > >> > >> >
> > >> > >> > Thanks,
> > >> > >> > Mike
> > >> > >> >
> > >> > >> > On Fri, Jan 12, 2001 at 03:54:43PM -0500, Rosen, Brian wrote:
> > >> > >> > > You can't say Context-W=*, or anything equivalent.
> > >> > >> > >
> > >> > >> > > Therefore, when you use Context=*, you are going to get back
> > >> > >> > > more than one action, and there is no way to indicate that
> > >> > >> > > you only wanted one action.
> > >> > >> > >
> > >> > >> > > It is valid to use Context=* when you use W-.
> > >> > >> > >
> > >> > >> > > If the command has an error, you could get back Context=*,
> > >> > >> > > so I don't think I've contradicted the Error response
> > >> > to CHOOSE.
> > >> > >> > >
> > >> > >> > > Brian
> > >> > >> > >
> > >> > >> > > > -----Original Message-----
> > >> > >> > > > From: Mike Broome [mailto:[email-masked]]
> > >> > >> > > > Sent: Friday, January 12, 2001 3:19 PM
> > >> > >> > > > To: [email-masked]
> > >> > >> > > > Subject: Re: Wildcard in ContextId
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > > Brian,
> > >> > >> > > >
> > >> > >> > > > When you say "wildcard response" do you mean there is no
> > >> > >> > way to get a
> > >> > >> > > > reply that contains "Context = *" or do you mean that it is
> > >> > >> > > > not valid to
> > >> > >> > > > use "W-" (the wildcard response indicator) on any of the
> > >> > >> > > > commands in an
> > >> > >> > > > action where the ContextID is wildcarded?
> > >> > >> > > >
> > >> > >> > > > The first interpretation is at odds with the recent
> > >> > >> > discussion in the
> > >> > >> > > > thread "Error response to a CHOOSE".  (It also would make the
> > >> > >> > > > change in
> > >> > >> > > > 6.21 in the IG that adds support for returning ALL as the
> > >> > >> > > > ContextID for
> > >> > >> > > > a transaction no longer needed, right?)
> > >> > >> > > >
> > >> > >> > > > The second interpretation would make an action like the
> > >> > >> > following --
> > >> > >> > > > with both ContextID and TerminationID wildcarded and a W- on
> > >> > >> > > > the command
> > >> > >> > > > -- invalid:
> > >> > >> > > >
> > >> > >> > > >     Context = * {
> > >> > >> > > >         W-Audit = * { ... }
> > >> > >> > > >     }
> > >> > >> > > >
> > >> > >> > > > If the above action IS valid, would the Reply have
> > >> > >> > "Context = *" or
> > >> > >> > > > would there be a separate action reply for every context?  My
> > >> > >> > > > preference
> > >> > >> > > > would be to have "Context = *" indicating the ContextID is a
> > >> > >> > > > don't care
> > >> > >> > > > (similar to what was discussed in the "Error response
> > >> > >> to a CHOOSE"
> > >> > >> > > > thread).
> > >> > >> > > >
> > >> > >> > > > Thanks,
> > >> > >> > > > Mike
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > > On Fri, Jan 12, 2001 at 08:21:58AM -0500, Rosen, Brian wrote:
> > >> > >> > > > > Wildcards are allowed in ContextId.  There is no
> > >> > way to get a
> > >> > >> > > > > wildcard response if you use a wildcard ContextId.
> > >> > >> > > > > We should probably point that out somewhere.
> > >> > >> > > > >
> > >> > >> > > > > Brian
> > >> > >> > > >
> > >> > >> >
> > >> > >>
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >>
> > >>
------------------------------------------------------------------------
> > >>                   Name: att1.htm
> > >>    att1.htm       Type: Hypertext Markup Language (text/html)
> > >>               Encoding: base64
> > >>            Description: Internet HTML
> > >
> > >--
> > >  Alcatel USA, Inc             Internet: [email-masked]
> > >  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
> > >  **** The opinions expressed are not those of Alcatel USA, Inc ****
> > >
> > >
> > >
>
> --
>   Alcatel USA, Inc             Internet: [email-masked]
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>
>   ------------------------------------------------------------------------
>                   Name: att1.htm
>    att1.htm       Type: Hypertext Markup Language (text/html)
>               Encoding: base64
>            Description: Internet HTML