#111: Section 4.1.8 "typ" (Type) Header Parameter Changes (by [email protected]):
* status: new => closed * resolution: => fixed Old description: > A. MAY is very bad word to be used here - how else MAY it be used? Need > to look at all of the 2119 language in this section and either correct it > or get rid of it. > > * FIXED > > B. The first sentence is not very readable. > > * FIXED? > > C. If it has no effect on JWS processing, then what does it affect - this > needs to be clarified. > > D. If the serialization is changed, does it make a difference between > JOSE and JOSE+JSON? Is there any reason to have the second one as you > cannot now in advance that it is json or compact. > > E. Is there a chance that the same value may mean different things > depending on if it is in the typ or ctyp member? If so then this is > going to be very hard to figure out for most people. > > F. Are MIME media type values collision resistant? Does this need to be > something that is discussed for the experts in reviewing entries here? > What happens if somebody defines a new media type that conflicts with a > value in the type registry? > > * FIXED - this is all MIME media types now. > > G. If it has no effect on JWS processing, then it should have no 2119 > language > > H. It says that type typ value SHOULD be ignored - under what > circumstances should it not be ignored. > > * FIXED New description: A. MAY is very bad word to be used here - how else MAY it be used? Need to look at all of the 2119 language in this section and either correct it or get rid of it. * FIXED B. The first sentence is not very readable. * FIXED? C. If it has no effect on JWS processing, then what does it affect - this needs to be clarified. * WON'T FIX - it says it is pointed at the appliction D. If the serialization is changed, does it make a difference between JOSE and JOSE+JSON? Is there any reason to have the second one as you cannot now in advance that it is json or compact. * WON'T FIX - It would be bad, but it would also be too late to make a real difference, you would have already decoded it. E. Is there a chance that the same value may mean different things depending on if it is in the typ or ctyp member? If so then this is going to be very hard to figure out for most people. * WON'T FIX - no longer quite such a problem since this is one registry - but still a potential future issue. F. Are MIME media type values collision resistant? Does this need to be something that is discussed for the experts in reviewing entries here? What happens if somebody defines a new media type that conflicts with a value in the type registry? * FIXED - this is all MIME media types now. G. If it has no effect on JWS processing, then it should have no 2119 language * DUP - bullet C H. It says that type typ value SHOULD be ignored - under what circumstances should it not be ignored. * FIXED -- -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- [email protected] | [email protected] Type: defect | Status: closed Priority: major | Milestone: Component: json-web- | Version: signature | Resolution: fixed Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/111#comment:2> jose <http://tools.ietf.org/jose/> _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
