Re: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-target

Dale,

I'm not sure what the alternative you suggest buys us.  The current ABNF
already provides the concept of a single parameter - the difference I
see is whether we have the "t=" prepended to the parameter value. I'm
not seeing that your ABNF change doesn't add extensibility either.  

Also, the change to the parameter names hasn't been so much that there
are new mechanisms being determined, but rather how we want to annotate
the current mechanisms by which the targets are determined.  So, I would
not anticipate much churn once we get agreement on the tagging. But, we
could certainly build extensibility by adding a generic-parm to the set
of possible values.  However, that suggests to me that we might want an
IANA registry for the values.  My concern here would be of course, that
rather than having the tags reflect how core SIP has determined the new
target, folks would be wanting to add tags that are service specific,
which contradicts the intent of the hi-target. 

Regards,
Mary. 

-----Original Message-----
From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
Behalf Of Worley, Dale (BL60:9D30)
Sent: Tuesday, July 07, 2009 2:56 PM
To: SIPCORE
Subject: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-target

Given the number of hi-target values and the rate at which we have been
changing them, perhaps we should have them be values of a single
parameter, rather than separate parameters.  That would allow
extensibility of this set with fewer interoperability problems.  E.g.,
change the BNF to:

   hi-target = "t" EQUAL ( "noop" / "predetermined" / "reg-uri" /
                           "reg-uri-alias" / "mapped" )

Dale

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore