Subject: Re: [salud] Another requirement

From: Laura Liess <[email-masked]>
Date: Tue, 1 Mar 2011 16:29:32 +0100

If people agree to add this as a requirement, I am OK with it. Maybe
we could find some more general wording for it?

And what should we do then with your first comment from your previous mail?

Laura

2011/2/25 Worley, Dale R (Dale) <[email-masked]>:
> [as individual]
>
> I'm behind on reading e-mail, so this may have been mentioned.  But I think that due to draft-ietf-bliss-shared-appearances, we have a requirement that the specific URN
>
> urn:alert:service:normal
>
> must function as a placeholder, that is, it has no particular semantics.
>
> Dale
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 1 Mar 2011 21:46:01 -0500

[as individual]
________________________________________
From: Laura Liess [[email-masked]]

And what should we do then with your first comment from your previous mail?
_________________________________________

One thing we should do is check with the authors of draft-ietf-bliss-shared-appearances whether this is significant to them.  Since I know Al Johnston, I should call him.

I haven't thought through the interaction between this proposed requirement and the discussion in section 3.1, the "service" family of URNs, although it seems to me that the problem is restricted to how to avoid any inconvenient collisions.  OTOH, section 3.1 is not a requirement, but a set of examples of a functionality we would like to support, so we don't have to resolve any conflicts, just have a reasonable expectation that we can resolve them well.

Dale

---

From: Laura Liess <[email-masked]>
Date: Wed, 2 Mar 2011 12:04:42 +0100

Dale,

DT and other IMS Service Providers we have the same problem with
urn:alert:service:call-waiting because it is already used in the 3GPP
specifications and already implemented. So I would be quite happy to
have this requirement.

Laura

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 2 Mar 2011 16:16:06 -0500

[as individual]  If 3GPP is already implementing one of these URNs, we should fix it in a requirement.

[as chair]  I just talked to Alan Johnston, and he said that the URN that is in the shared-appearances draft (urn:alert:service:normal) is still very mutable.  The draft will go through at least one more revision, and the implementers are waiting until the draft is finalized before they build systems based on it.

Dale

---

From: Laura Liess <[email-masked]>
Date: Thu, 3 Mar 2011 15:55:12 +0100

We could try, also I am not sure people would accept it.
> [as chair]  I just talked to Alan Johnston, and he said that the URN that is in the shared-appearances draft (urn:alert:service:normal) is still very mutable.  The draft will go through at least on…
And what is your proposal? How should we handle this issue?

Laura

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 4 Mar 2011 17:15:48 -0500

> We could try, also I am not sure people would accept it.

[as chair] I suggest writing up a proposal about it and publishing it
on the Salud list as a discussion point.  Based on what people say,
add what you think should be added to the requirements.

[as individual] I do not see the fixing the call-waiting URN as being
a significant burden.  Within each major approache we've been
discussing, we can tweak the syntax to make the "semantic" indicator
for call-waiting be "urn:alert:service:call-waiting".

> > [as chair] I just talked to Alan Johnston, and he said that the
> > URN that is in the shared-appearances draft
> > (urn:alert:service:normal) is still very mutable.  The draft will
> > go through at least one more revision, and the implementers are
> > waiting until the draft is finalized before they build systems
> > based on it.

> And what is your proposal? How should we handle this issue?

[as individual] I think this implies that the shared-appeareances work
only requires that there be a URN that is a "placeholder" and does not
carry specific semantics.  So the requirement can be weaked to say
that such a URN must exist, but the requirement should not specify
what the URN is specifically.  (This is different from the
call-waiting URN, where 3GPP has already started implementing a
particular value for the URN.)

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Mar 2011 18:42:52 -0500

> for call-waiting be "urn:alert:service:call-waiting".

If fitting this particular URN can be gracefully integrated into a 
general approach, they that is great. If it doesn't fit well, then I 
suggest defining the general approach so this URN doesn't intrude on it, 
and then define this URN as a grandfathered alias.

E.g. Just leave all of urn:alert:service out of the general scheme, and 
define this as a special case with an equivalence to something that *is* 
in the general scheme.

(I'm so tired of hearing about "services" that I would like to strike 
the word from the language.)

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Tue, 8 Mar 2011 14:34:14 +0100

Dale,

We already have a general requirement concerning service
interoperability (REQ-12).  I don't think we can require a particular
format for a particular use case. So I would leave this issue for
later discussions about the alert-info urn values definitions (section
5).
It this OK for you?

Laura