Subject: Re: [Ieprep] Re:

From: [email-masked]
Date: Thu, 23 May 2002 10:07:26 EDT

In a message dated 5/22/02 4:54:36 PM Eastern Daylight Time, 
[email-masked] writes:

> > Sorry, I know it was somewhat contorted. We're trying to define a 
> namespace 
> > which is used for a particular environment or network - in this case - in
> >  the public network of a country. The network, and therefore the 
> namespace, 
> > needs to support what we call IEPREP or ETS, but it must also support 
> normal 
> > calls and 911 calls. So it seems to make sense to define a set of 
> priority 
> > values in that namespace which includes all these known things in one 
> set. 
> 
> ok, I kinda of suspected that you were revisting the issue of "normal".
> I'll restate my objection a while back of requiring/expecting the
> specification of the "normal" value in the Resource-Priority header.  
> its redundant, and therefore in my opinion a waste of cycles.  its 
> perfectly fine to state that a given value of a list of 2 or more is 
> treated as default.  but "normal" should never be a requiredor expected
> value
> 
> also, a small nit, but i don't think there should ever be a namespace
> called IEPREP.  
> 
> -ken
> 
> 

Good, then we agree to not have a namespace called IEPREP.

Yes, my above comment mostly relates to the need to define a "normal" value 
within this new namespace. I believe you are saying that there should not be 
a "normal" value defined. I'm thinking about how one would make a statement, 
either in the ID or in a network's own documentation, of the default 
treatment (if the header is missing or has an unknown value). It seems 
appropriate to be able to say something like: "It MUST be treated as if it 
contained a header with a priority value of ____". I need something to put in 
that blank.

I don't understand your point that it would be "a waste of cyles". Sure, I 
suppose that any implementation might take some additional "cycles" for every 
possible value that is defined, but then, if you were worried about processor 
power to parse out the text string, you would not use text strings in the 
protocol.

And for those who don't want to talk about protocol details here (which we 
shouldn't), I am trying to settle out the issue of how many values need to be 
in this namespace and what they are. This isn't really protocol detail, 
except that SIP has made it into detail by using the actual text string of 
the name of the value in the protocol.

Mike

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 23 May 2002 17:11:30 +0100

so, when I said before, "I'll restate my objection a while back of 
requiring/expecting the specification of the "normal" value in the 
Resource-Priority header.",  its the *requiring/expecting* part of 
anyone that defines a NameSpace that I want to avoid.  

I'm not in a position to say that you can't specify a "normal" value, I
just prefer that it not be there.  And I definitely want to avoid anyone
else feeling that they must put in a "normal" value.

i also feel that the concern about protocol discussion has become a bit 
too strong, but I'll respond privately about why I prefer "normal" not 
be there with respect to protocol design.

-ken

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