Subject: Wildcard in ContextId

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 12 Jan 2001 08:21:58 -0500

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

---

From: Sankar Raman <[email-masked]>
Date: Fri, 12 Jan 2001 12:44:44 -0500

CHOOSE is also a form of wildcard. In this case
A CHOOSE contextId has to be returned if the MG failed to create
a new context.

---

From: Mike Broome <[email-masked]>
Date: Fri, 12 Jan 2001 15:19:15 -0500

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

---

From: Michael Brown <[email-masked]>
Date: Fri, 12 Jan 2001 15:14:46 -0500

Yes, we should. IMO this is a more general statement of the issue
discussed earlier  about the inability to generate a concise list of
contextids in an audit response when specifying ALL for contextid and
ROOT as the terminationid. While, as suggested, multiple actionreply
constructs can produce an answer, it is rather cumbersome. The decision
in that case was that syntax for a list of contextids would be
considered for V2 work. Perhaps defining a generalized wildcard response
for wildcarded contextids would be a better approach. In the meantime,
the issue could be recorded in the Implementor's guide in the section
that suggests the use of multiple actionreply constructs for returning a
list of contextids.

Michael

---

From: Christian Groves <[email-masked]>
Date: Mon, 15 Jan 2001 17:21:37 +1100

G'Day Mike and Brian,

Yes I agree that we need to point this out somewhere as it keeps coming
up and "wildcard" seems to be a loaded term as we can do "all" or
"choose" which are both wildcards.

Implementors' Guide :
7.1     Returning a Context ID List
7.3     Audit Response with and without wildcard response (w-)
talk about this but I think we should probably put something in the main
text.

How about:
1.9 Wilcarding Context IDs

Description:     Wildcarding ContextIDs is allowed however it is poorly
specified in the current specification.
Reference:      Subject: Re: Wildcard in ContextId
Date: Fri, 12 Jan 2001 15:14:46 -0500
From: Michael Brown [email-masked]
Organization: Nortel Networks
To: [email-masked]
 [Begin Correction]
6.11 Context Attributes and Descriptors
The attributes of Contexts are:
§ ContextID. >>>>A wildcarding mechanism using two types of wildcards
can be used with ContextIDs.  The two wildcards are ALL and CHOOSE.  The
former is used to address multiple Contexts at once in a command request
and/or reply, while the latter is used to indicate to a media gateway
that it must select a Context or from the media gateway that it cannot
select a context. <<<<<
 [End Correction]

Cheers, Christian