Subject: Re: [Sip] WGLC for URI and Header Parameter Registries

From: William Marshall <[email-masked]>
Date: Thu, 23 Oct 2003 08:35:43 -0400 (EDT)

Two comments regarding draft-ietf-sip-parameter-registry-00:

(1) In the IANA registry for header parameters, I do not think it
should be necessary to include every parameter that is defined in the same
document that defines the header.  A single reference to the header
document should be sufficient (which is already done in another IANA
registry).  It is really only the extensions that we need to be
concerned with, e.g. those defined in the original document as 
"token EQUAL value".
I really do not think it is a burden on someone defining a new
parameter to check the document referenced in the header registry
for all initial parameters, and to not conflict with those.
This could even be made a little easier by including two document
references for every parameter extension - first to the base spec 
that defines the header, and second to the spec that defines the
new parameter.

If the above comment is accepted, then the initial list becomes
much shorter, including (I believe) only the Via parameters comp
and rport (which should reference RFC 3581).

If the above comment is not accepted, then the initial list is much
too short.  There are numerous other parameters defined in current
RFCs.  For instance, in 3261, the Authorization header includes 
parameters "username", "uri", "qop", "cnonce", "nc", and "response",
in addition to the "auth-param-name = token" extension.  Likewise
the "Proxy-Authenticate" header has a mechanism defined for 
extensions, so needs its current parameter names included in the
registry.

(2) There are other "parameters" that are defined for headers that
are not of the simple form "token EQUAL value", but rather just as
"token".  These should also be included in the registry.   Section 
4.1 of the draft should includes examples of both of these cases.

One example is the "Privacy" header defined in RFC 3323, which includes 
"token" as one of the options for "priv-value"; any document that 
defines one of these new tokens should have its value registered too.  

If the decision on point (1) above is that all existing parameters
need to be included in the registry, then "header", "session", "user",
"none", and "critical" also need to be added to the list.  Also,
in RFC3261 are headers such as "Priority" that have extensions defined
like this.

Bill Marshall
[email-masked]

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: William Marshall <[email-masked]>
Date: Thu, 23 Oct 2003 15:29:36 -0400 (EDT)

Dean wrote:
> > > 
> > > One alternative that might make you happier is a policy of
> > > "Specification Required", where that specification can be any publicly
> > > acessible body of work recognized by the RFC Editor, including ITU and
> > > 3GPP specs.
> > 
> > This sounds great, and does make me happier actually :)
> 
> OK, so would we all (except maybe Bill Marshall, who just proposed a
> "very short list" approach) be happy with "Specification Required"
> language that would allow registration of a parameter based on 3GPP
> specifications without an RFC?

I don't think I was disagreeing with this at all.  The parameter values
clearly need to be documented, and somewhere where their definition
can be retrieved easily by everyone.  

My argument for the "very short list" is that the "initial" bunch of 
parameter values, documented in the same RFC as where the header is 
documented, should not need to be added to the IANA registrary 
as "additional" parameters.

Bill Marshall
[email-masked]